Blazor Byte Array Interop Support

[TanayParikh]

Implements changes discussed in #32259.

Fixes: #21877

[pranavkm]

Suggested change

	else if (data.Length + jsRuntime.ByteArraysToBeRevivedByteLength > (31*1024)) // TODO; get this limit from SignalR somehow?
	else if (data.Length - 32k > jsRuntime.ByteArraysToBeRevivedByteLength) // TODO; get this limit from SignalR somehow?

To avoid int overflows.

[TanayParikh]

I believe this should be:

Suggested change

	else if (data.Length + jsRuntime.ByteArraysToBeRevivedByteLength > (31*1024)) // TODO; get this limit from SignalR somehow?
	else if (32k - data.Length < jsRuntime.ByteArraysToBeRevivedByteLength) // TODO; get this limit from SignalR somehow?

[TanayParikh]

Still doing ToArray in place of passing through the ReadOnlySequence<byte>.

Concerns with using the ReadOnlySequence relate to the fact that it doesn't implicitly cast to byte[] so when we're examining method parameters we have a type mistmatch.

Additionally, as Javier mentioned in the other PR we need to verify the lifecycle/ownership of the ReadOnlySequence.

[SteveSandersonMS]

Concerns with using the ReadOnlySequence relate to the fact that it doesn't implicitly cast to byte[] so when we're examining method parameters we have a type mistmatch.

I think you'd need to change the receiving code (ComponentHub.SupplyByteArray) to accept a ReadOnlySequence<byte> instead of a byte[], so there wouldn't be a type mismatch.

Agreed on verifying the ownership of the buffer before doing that though.

[javiercn]

Yes, lets keep it as is for the time being and then we can do a quick check and change afterwards.

[TanayParikh]

Had to revert the ByteArrayJsonConverter back to a previous version (f710bd0) due to ongoing compatibility issues in WASM/CI. Not able to repro the issue locally, and tried logging/different solutions, but not too efficient given each attempt needs to be run through the entire CI pipeline to see if it works.

f710bd0 follows the same pattern as the JS/DotnetObjectReferenceJsonConverter so I don't think this should be a big deal.

[javiercn]

This looks fantastic!

I have one small comment that needs clarification. Other than that, this is good to go!

[javiercn]

Good to go!

[TanayParikh]

Breaking change announcement proposal:

Byte Array Interop in .NET 6.0 Preview 6

Labels:

• Breaking Change
• Enhancement
• Release

Summary

Blazor Server & WebAssembly now supports optimized byte array interop which avoids encoding/decoding byte arrays into Base64, facilitating a more efficient interop process.

Breaking Change

Receiving Byte Arrays in JS

function ReceivesByteArray(data)
{
	// Previously data was a Base 64 encoded string representing the byte array
	// 6.0 Preview 6 and beyond, it'll be a Uint8Array (no longer requires processing the Base 64 encoding)
}

which can be invoked by the following C# code:

var bytes = new byte[] { 1, 5, 7 };
await _jsRuntime.InvokeVoidAsync("ReceivesByteArray", bytes);

Sending Byte Arrays from JS

If .NET is expecting a byte[] JS must provide a Uint8Array. Previously, it was possible to provide a Base64 encoded array using btoa.

For example, if you have something like this:

var bytes = await _jsRuntime.InvokeAsync<byte[]>("someJSMethodReturningAByteArray");

then you must provide a Uint8Array from JS (must not be Base 64 encoded).

Before:

function someJSMethodReturningAByteArray() {
    const data = new Uint8Array([ 1, 2, 3 ]);
    const base64EncodedData = btoa(String.fromCharCode.apply(null, data as unknown as number[]));
    return base64EncodedData;
}

After:

function someJSMethodReturningAByteArray() {
    const data = new Uint8Array([ 1, 2, 3 ]);
    return data;
}

PR: #33015
Issue: #21877

[SteveSandersonMS]

Announcement looks great. Suggested tweaks:

Blazor Server & WASM now supports optimized byte array interop

Replace WASM with WebAssembly.

Receiving Byte Arrays in JS

For context, can you also show the corresponding .NET code that invokes this?

Previously, it was possible to provide a Base 64 encoding array

Typo: "Base 64 encoding array" should be "Base64 encoded array"

[TanayParikh]

Thanks @SteveSandersonMS, it's official dotnet/announcements#187!

[guardrex]

@TanayParikh / @SteveSandersonMS ... The announcement isn't labeled (and placing "in .NET 6.0 Preview 6" in the title isn't normal and doesn't filter well), so it's a bit hidden at the moment. dotnet/announcements#187

[ghost]

Hi @guardrex. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[TanayParikh]

@TanayParikh / @SteveSandersonMS ... The announcement isn't labeled (and placing "in .NET 6.0 Preview 6" in the title isn't normal and doesn't filter well), so it's a bit hidden at the moment. dotnet/announcements#187

Thanks for pointing that out @guardrex, I had tried adding labels but I don't have the adequate permissions. Do you happen to have the required permissions or know how I can get them? I'd like to add in the following labels.

• Breaking Change
• Enhancement
• Release
• .NET 6.0

Also, are you familiar with how the change goes from dotnet/announcements to https://docs.microsoft.com/dotnet/core/compatibility/6.0#aspnet-core?

[guardrex]

I don't have permission ... I'm just a docs 🐈.

Open a new issue here on the PU repo. They prefer not to work from closed issues/PRs like this.

WRT the breaking change doc ... submit a docs issue (and possibly PR) for it. It looks like the docs aren't autogenerated but actually worked up manually and then modified manually. I see dev PRs going into it on the blame .....

https://github.com/dotnet/docs/blame/main/docs/core/compatibility/6.0.md

Use the This page button at the bottom of the topic to open the issue and go from there.

[ghost]

Hi @guardrex. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.