Type discrepancies when working with JS/WASM Web Workers

[d-markey]

Background: I maintain a package dealing with Web and native multithreading and recently ported it to Wasm. I've come across various issues especially in terms of type management (how to reenter Dart-land and regain strong types after a payload was sent with postMessage()) but eventually managed to complete the migration. Some articles were very helpful eg. #55203.

Issue: recently, a user reported a bug where they're sending a Map<int, double> to a WASM Web worker, causing the worker to fail with exception message JSString is not a subtype of type num in type cast.

At first, I thought the issue was likely in user-code because I didn't understand why a Map<int, double> payload would cause a problem related to some JSString.

It turns out it's a real issue and Map<int, double> is effectively received by the worker as a Map<Object?, Object?> (that is expected) with values of type double (OK also) but with keys of type JSStringImpl (not OK).

I've implemented a quick test to reproduce --> https://github.com/d-markey/wasm-test

Turns out the keys of a Map<bool, bool> are also received by the worker as JSStringImpl in WASM (String in JS).

Does anyone know whether this is a Dart issue, or by design per postMessage() / structured-clone spec, or maybe due to some browser-specific implementation? Will keys of a map always materialize as Strings or JSStrings after going through postMessage()?

I managed to implement a quick fix for this issue, but it really looks like a hack IMHO. I would like to know if there's a better way to go to ensure key types are preserved, or maybe if this is a bug in Dart's runtime that could be fixed?

All comments welcome!

[dart-github-bot]

Summary: WebAssembly worker receives Map keys as JSStringImpl instead of their original type after using postMessage(), causing type errors. A workaround exists, but a proper solution is needed.

[mraleph]

This behavior is expected and has nothing to do with Web Workers, it happens because you jsify the Map.

Though I must admit jsify documentation should probably be clearer about it (cc @srujzs). JavaScript objects do not support arbitrary keys: they only support properties with strings (and symbols) as names. Thus converting Map to a JavaScript Object forces all keys to be strings:

final map = {1: "one", 2: "two"}.jsify().dartify();
print((map as Map).keys.first is String);  // true

If you want to preserve types you need to write your own custom serialization function.

[d-markey]

I believe it has to do with Web Workers because using postMessage requires an instance of JSAny. Otherwise, there would be no reason to use jsify at all, and it would work seamlessly like Isolates on VM platforms.

Regarding maps in browser world, so I understand they're handled by Dart as plain JavaScript objects and not JavaScript Maps?

Thanks for the response, I'll update my package's doc to mention this limitation.

[mraleph]

Regarding maps in browser world, so I understand they're handled by Dart as plain JavaScript objects and not JavaScript Maps?

The actual Map implementation is using a complicated setup with multiple objects used as dictionaries to faithfully implement Dart's semantics (which does not directly map to ES6 Map semantics). (See also #53162). The jsify a JS object from Dart Map by doing effectively this:

final o = JS("{}"); 
for (var e in m.entries) {
  final k = e.key.jsify();
  final v = e.value.jsify();
  JS("#[#] = #", o, k, v);
}
return o;

That's how keys and up being strings. (e.g. try consider let o = {}; o[{}] = 1; console.log(o); in JS).

Thanks for the response, I'll update my package's doc to mention this limitation.

You could make it work better if you don't rely on jsify but instead perform conversion yourself.

[d-markey]

Hello,

I've been thinking about it some more but it's impracticable in the context of a general purpose package, where I don't know the shape of the data structure in advance (eg. nested maps/list etc). I understand the purpose of jsify()/dartify() is interop with JS as opposed to marshaling.

I believe I can come up with a solution where a custom Dart map would jsify to a JS Map (with JS keys) instead of a JS Object. I see no JSMap in js_interop, so this is new and a JS Map could be dartified back to a map with better typing of keys. I believe this would not be a breaking change, but would the Dart team even consider a pull request if I were to fork and propose something?

[srujzs]

Though I must admit jsify documentation should probably be clearer about it (cc @srujzs).

I've been tracking many of these requests (jsify/dartify in general need some improvements) in #55222, so I'll add it there.

I've been thinking about it some more but it's impracticable in the context of a general purpose package, where I don't know the shape of the data structure in advance (eg. nested maps/list etc). I understand the purpose of jsify()/dartify() is interop with JS as opposed to marshaling.

jsify ultimately is a straightforwardish recursive algorithm that users can replicate themselves with the combination of isA/interop type checks, Object.keys, [] external operator, and maybe a couple other built-in interop functionalities, but I'd need to understand a bit more about some of the complexities that may make this difficult to hand-roll. If you have some examples where this gets difficult, I can understand a bit better and help.

with better typing of keys

jsify could do this today, but it requires some examination of keys and values to get the least upper bound type. Such type tests are likely to add a performance cost, but we've considered adding an optional parameter for that. Ideally with a JSMap.toDart API, we can require type args to be passed, and if the keys and values do not match the provided type args, there will be a cast failure.

I believe this would not be a breaking change, but would the Dart team even consider a pull request if I were to fork and propose something?

Yes. :) A similar request is already filed here: #54365.

[d-markey]

Hi @srujzs

The problem I'm trying to solve is to send arbitrary (well, almost arbitrary) data from the main browser thread to a worker thread.

Using my library and a bit of code generation, users of my package should be able to write something like:

   final res = await myServiceWorker.remoteMethod(x, y, z);

Users implement their own class and service methods (MyService + remoteMethod), and a builder generates a "proxy" worker class (MyServiceWorker) that implements the original one. This class holds the plumbing necessary to initialize MyService in a Web Worker + the communication to/from the worker. Typically, invoking a remote method is handled by the proxy class by sending a message to the worker where arguments (x, y, z) have been packed in a List (users are recommended to use primary types like int, String, bool... but also List and Map -- if they want something else, it is still possible provided they implement a marshaler so a custom object state is transported as primary types and is reconstructed on the receiving end).

The communication relies on JS postMessage() and that's where I need to jsify() the payload because in Dart's web package, postMessage() only accepts JSAny?.

So jsify() here is used for interop, but in the case of postMessage(), there's a marshaling aspect to it too, where data resurfaces on the other side.

I've managed to work around int/double discrepancies between JS and Wasm, but I didn't see the issue with Maps where keys are converted to Strings no matter what. I would like the worker to receive data that is as close as possible to the original data. So if the user is calling the remote method with a Map<int, double> argument, it should be received by the worker as a Map<dynamic, dynamic> where keys are ints and values doubles. I don't expect a strongly typed map, so there's no need to check keys and values to find the least upper bound type.

I've had a look at the tooling required to try and modify the runtime, I'm not sure I'll go ahead with a pull request after all! I'll try if things set up easily and if I can get my head around the runtime's internals. I've already found where jsify/dartify are patched in the JS/Wasm runtime, but I'm not sure it would be enough to just amend these places. For instance, I'm not sure I understand how interceptors are used and if I should modify them if I implement a JSMap.

I believe if you are able to add support for JSMaps in js_interop and modify dartify() so it builds a proper Dart Map when presented a JS Map, that would help me a lot :-) It shouldn't be a breaking change because jsify() is left unchanged, so it's only a matter of dartify() properly handling JS Maps.

[d-markey]

Very interesting read in #55222, thanks for the link.

I will let the Dart team work on jsify/dartify for now as it might be deeply reworked, and will try to adapt to the direction you'll be taking with interop eg. if there's a way for me to implement custom jsify/dartify.

I would avoid restricting to only JSON-like stuff though, as there are a bunch of things that can be passed via postMessage eg. MessagePort, AudioData, Error, ... and even plain Objects!

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#supported_types

[srujzs]

I don't expect a strongly typed map, so there's no need to check keys and values to find the least upper bound type.

Ack, good to know.

For instance, I'm not sure I understand how interceptors are used and if I should modify them if I implement a JSMap.

If you're more or less familiar with how interceptors work (see https://github.com/dart-lang/sdk/blob/main/pkg/compiler/doc/interceptors.md for a deeper dive), there isn't a specific one for JS Map anywhere. Therefore, it gets intercepted as LegacyJavaScriptObject (which <: JavaScriptObject, which in turn subtypes JSObject indirectly), and so treating at as a JSObject is okay. You should be able to just modify the patch files and it should be good enough. But yes, I can see how working in the internals/patch files can get quite messy. :)

I think there are two main asks here:

1. Adding a callback parameter to jsify/dartify to allow custom conversions or easily building a jsify/dartify using building blocks. I'd like to prioritize this first as (2) can be more or less built using this and existing interop. Here, it can be as simple as a function that type-checks Dart and JS Maps and recurses on the keys and values.
2. Adding JSMap, adding its conversion functions, and handling it in jsify/dartify.

[d-markey]

Thanks for following up!

My two cents:

1. Adding a callback parameter to jsify/dartify to allow custom conversions or easily building a jsify/dartify using building blocks. I'd like to prioritize this first as (2) can be more or less built using this and existing interop. Here, it can be as simple as a function that type-checks Dart and JS Maps and recurses on the keys and values.

I've tried to implement something on my lib side (id est not in Dart's runtime and obviously without this improvement), but there's a pitfall when there are circular references in the overall structure. The callback will need access to the map of already seen and processed objects.

2. Adding JSMap, adding its conversion functions, and handling it in jsify/dartify.

Would be great, but also a breaking change since a Dart Map would produce a JSMap instead of a JSObject. It seems some JS APIs will accept a plain object but would not recognize a JS map, eg. the options argument passed to fetch if I remember the few tests I've tried (or maybe it was the headers collection, can't remember exactly). Maybe jsify should also handle some other type to be converted to JSObject, like Expando maybe?

EDIT: alternatively, Map<String, _> could keep being converted to JSObject, while maps with other key types would convert to JSMap. Seems less of a breaking change.