[dart:js_interop] Can't box a List.

[ykmnkmi]

Got Uncaught Error: Attempting to box non-Dart object.:

import 'dart:js_interop';

void main() {
  print([1].toJSBox); // here
}

WASM prints [object Object].

Dart 3.3.0 on "windows_x64".

[mdex-geek]

the toJSBox method is not a standard method in Dart or the dart:js_interop library

[ykmnkmi]

toJSBox

[lrhn]

Probably a symptom of dart2js using JS Array objects to implement List. It is both a Dart object and a JS object. The test to allow the operation should be "is Dart object", not "is not JS object".

[ykmnkmi]

@lrhn DDC throws this error too.

[lrhn]

Probably for the same reasons. Labels should cover all web interop.

[srujzs]

Lasse is correct here. Specifically, the test is is JavaScriptObject, where the type is an interceptor the JS backends use to distinguish between Dart objects and JS objects.

Importantly, core Lists are both on the JS backends, as they are just an interceptor (JSArray) that subtypes JavaScriptObject. So, you see the above error claiming that it's a JS object. You don't see this on dart2wasm because Lists are a Wasm type there.

One way we could fix this is to allowlist Lists and typed data (which have the same issue), but then we get the opposite issue, where you're allowed to box JSArrays or JSTypedArrays, because they're just extension types for the equivalent Dart type on the JS backends.

The central goal of toJSBox is to prevent users from accidentally interacting with Dart objects in JS or passing them to a separate Dart runtime.

A secondary goal is to provide a distinction between JS objects and Dart objects so that users don't needlessly box JS objects.

If we want to support boxing Lists and typed data and have them consistently work on all web backends, it might be worth relaxing this secondary goal. If we want to still maintain the secondary goal and be okay with users boxing JSArrays and JSTypedArrays, we could add some additional type checks.

[ykmnkmi]

My case is to pass Dart objects to Svelte 5 signals:

/**
 * @template V
 * @param {V} initial_value
 * @returns {import('../types.js').SourceSignal<V>}
 */
/*#__NO_SIDE_EFFECTS__*/
export function mutable_source(initial_value) { /* body */ }

/**
 * @template V
 * @param {import('./types.js').Signal<V>} signal
 * @returns {V}
 */
export function get(signal) { /* body */}

Here are the Dart bindings:

extension type Signal<T>(JSObject _) implements JSObject {}

extension type SourceSignal<T>(JSObject _) implements Signal<T> {}

@JS('mutable_source')
external JSObject _mutableSource(JSBoxedDartObject? value);

SourceSignal<V> mutableSource<V>([V? value]) {
  return SourceSignal<V>(_mutableSource(value?.toJSBox));
}

@JS('get')
external JSBoxedDartObject? _get(JSObject signal);

T get<T>(Signal<T> signal) {
  var boxed = _get(signal);
  return boxed?.toDart as T;
}

I try to split the implementations between JS using unsafe casts (dart-lang/web#180) and WASM using boxing.

[ykmnkmi]

How to check WASM compilation in conditional imports?

[srujzs]

I think we actually want to support that use case (Signals) through an unsafe type soon to avoid the overhead of boxing e.g. JSUnsafeDartObject which is just an extension type on the raw type. It would offer no consistency guarantee and would mostly only be useful for cases like this.

dart2wasm vs dart2js/ddc can be checked using dart.library.html: https://dart.dev/interop/js-interop/package-web#conditional-imports

[ykmnkmi]

This was solved using ExternalDartReference.