Custom event args cannot include byte arrays or DotNetObject instances #34338
Labels
area-blazor
Includes: Blazor, Razor Components
bug
This issue describes a behavior which is not expected - a bug.
Done
This issue has been fixed
Milestone
This is a small bug introduced recently (by me, I think) due to an optimization.Update: No, after investigation, I realise this was never supported, because the event dispatch was not via JS interop (on Server and WebView).Our updated logic for dispatching events now does its own JSON serialization (so it can do its own UTF8 encoding, so the .NET side doesn't have to convert UTF8->String->UTF8). The logic looks like
const utf8 = textEncoder.encode(JSON.stringify(data));
This is inconsistent with how the serialization works for JS interop, in that JS interop uses its own arg replacer that deals with things like formatting
DotNetObject
orUint8Array
.We do actually have an E2E test showing you can include special types in the event payload, but unluckily, it happens to be
IJSObjectReference
that happens to serialize into the right shape usingJSON.stringify
alone.Fixing this
... should be very simple. We export some new function
stringifyAsArgs
or similar onto JS interop'sDotNet
, and call that instead ofJSON.stringify
.Better still, we should bake in this "I want to send it as UTF8 bytes" pattern, since we're using it in multiple places. We could export a special type
Utf8BytesParameter
fromDotNet
that changes the serialization rule for that parameter.Update: No, those suggestions are nonsense. The second one doesn't make sense because we're not sending the message via JS interop, so there's nothing to implement this. The first one is bad because it breaks the layering and means we wouldn't be able to guarantee that things like
byte[]
messages correctly appear just before corresponding JS interop calls. A bigger solution is needed.The text was updated successfully, but these errors were encountered: