Lists created with list.cast() don't work translate to Arrays on js-side with js-interop

[a14n]

With the following html file:

<script>
  function f(list) {
    console.log(list);
    console.log(typeof(list[0]));
  }
</script>
<script defer src="page.dart.js"></script>

and the following dart file:

import 'dart:js_util';
import 'package:js/js.dart';

@JS()
external Object get window;

void main() {
  var l = <dynamic>[1, 2, 3];
  callMethod(window, 'f', [l]);                      // OK
  callMethod(window, 'f', [l.cast<int>()]);          // ERROR
  callMethod(window, 'f', [l.cast<int>().toList()]); // OK
}

I get the following console output on chrome:

Array(3)
number
CastList.new
undefined
Array(3)
number

As you can see using only l.cast<int>() leads to unusable array on js side. A workaround is to call .toList() to get back an Array.

Version :

$ dart --version
Dart SDK version: 2.17.3 (stable) (Wed Jun 1 11:06:41 2022 +0200) on "linux_x64"

[a14n]

/cc @sigmundch

[sigmundch]

/cc @srujzs

Thanks @a14n for the detailed report!

Unfortunately this is by design, but we want to make the experience here better. Our plan in the future is to make typing of js-util/jsinteorp a bit stricter to make it clear that only JS types (and an array list is one of them) can be passed through JSInterop. Hopefully doing so will alert developers earlier in the development process.

BTW - the issue on Encoding.decodePath came to our attention earlier, so I'll add a comment there momentarily.

[a14n]

Do you have an example of how this will be done? In my above code l.cast<int>() and l.cast<int>().toList() have the same List<int> type and I don't really see what static check could be done here.

[sigmundch]

We are not sure yet - but we've been exploring the idea of having an explicit JSArray type that is used for JSInterop, but that has zero cost to convert to it from natively implemented Lists.

At the low-level primitives (like in dart:js_util), we may have to expose conversion functions. Similar to how we use allowInterop today to pass callback functions, we'd need something equivalent for Lists (maybe using extension methods to make the API more fluid). In fact, our hope is to change allowInterop to return a JSFunction (rather than the same Dart Function type) and use that JSFunction type as a static requirement for callbacks.

We are still debating a lot of this, though. Also, we haven't discussed much what could be the best model at the high-level JSInterop (like in package:js). We could do the same thing as the low-level primitives and expose these new static types. But we could alternative make some of the conversions automatic (or semi-automatic with the use of some annotations)

[sigmundch]

So, in terms of your example:

  // Note: now js_util exports globalThis, so no need to separately expose window :)
  callMethod(globalThis, 'f', [l]);                         // ERROR : List<List<int>> is not a List<JsAny>
  callMethod(globalThis, 'f', [l.toJSArray()]);             // OK
  callMethod(globalThis, 'f', [l.cast<int>().toJSArray()]); // OK

The second case will have zero cost, the third-case will be like using .toList()

[sigmundch]

Sorry I meant to share a comment in your google-maps bug yesterday and I lost my draft unfortunately. I was going to mention that there is a tradeoff in how to fix an API like Encoding.decodePath. If you cast the result within the google-maps package, then the cost of the cast is present for everyone using the API. If you feel such an API could be performance critical and you rather not have the cost of the cast, you could expose it instead as a List<Object?>.

One aspect of the design space we haven't discussed is whether we can do better with static JSInterop. In our static JSInterop effort we are going with an approach based on erasure. We already treat any JSInteorp type as if it was JSObject, and simply use the type just to access static extension methods.

In that world, List<LatLng?> would be equivalent to List<JSObject?>. It's still TBD to evaluate whether we can change the default interpretation of JSArray to be a List<JSObject?> (instead of List<Object?>). If that's possible, then we may be able to reach a point where it would be valid to write what you originally had in the google-maps package.

[a14n]

I was going to mention that there is a tradeoff in how to fix an API like Encoding.decodePath. If you cast the result within the google-maps package, then the cost of the cast is present for everyone using the API. If you feel such an API could be performance critical and you rather not have the cost of the cast, you could expose it instead as a List<Object?>.

The main purpose of my google_maps_package is to provide a dartified experience on top of the google maps API (with type checking, getter/setter instead of getXxx(), event streams...). Using List<Object?> instead of List<LatLng> is a defeat in that goal. So for now I think I will have to add .toList() everywhere I was previously using .cast<Xxx>>().

One aspect of the design space we haven't discussed is whether we can do better with static JSInterop. In our static JSInterop effort we are going with an approach based on erasure. We already treat any JSInteorp type as if it was JSObject, and simply use the type just to access static extension methods.

In that world, List<LatLng?> would be equivalent to List<JSObject?>. It's still TBD to evaluate whether we can change the default interpretation of JSArray to be a List<JSObject?> (instead of List<Object?>). If that's possible, then we may be able to reach a point where it would be valid to write what you originally had in the google-maps package.

I like this notion of erasure where you have the hability to have types on your API that the static analysis uses to prevent bad usage at development time and where you have almost 0-cost after compilation.

Is this comment (that you made early last year) still relevant ?

[sigmundch]

(sorry for the slow response, just returning from PTO)

Yes - that comment is still relevant and the path we are pushing forward. We don't have the static-views syntax (like the newtype example I showed there), but we have a @staticInterop annotation in package:js that allows us to approximate the semantics of that future. It's still in development, so it will still have sharp corners, but you may be interested in checking it out.

See as an example https://pub.dev/packages/js#interop-with-native-types-using-staticinterop