Cast error when awaiting enumerateDevices()

[davidjenkins]

Dart version 2.7.0 (build 2.7.0-dev.2.1 e4344a5) -- included with Flutter (Win 10 x64)

This issue also occurs in current dev branch of Flutter, which uses Dart 2.7.0 (not sure if "2.7.0" alone means "2.7.0-dev0.0").

If I try this:

import 'dart:html';
// ...
await window.navigator.mediaDevices.enumerateDevices();

Then I get this (in Chrome):

Type 'List<dynamic>' should be 'List<MediaDeviceInfo>' to implement expected type 'FutureOr<List<MediaDeviceInfo>>'.

Full stack:

errors.dart:147 Uncaught (in promise) Error: Type 'List<dynamic>' should be 'List<MediaDeviceInfo>' to implement expected type 'FutureOr<List<MediaDeviceInfo>>'.
    at Object.throw_ [as throw] (errors.dart:196)
    at Object.castError (errors.dart:45)
    at Object.cast [as as] (operations.dart:426)
    at Function.check_FutureOr [as _check] (future.dart:44)
    at js_util_dart2js.dart:145

[sigmundch]

@terrylucas - this appears like an error in the generated dart:html code.

I believe we'll hit this issue in other APIs as well, basically anywhere we have promiseToFuture<List<X>> today, I expect the underlying list to be a List<dynamic> (or List<JSAny> once we add support for it)

[rakudrama]

Can we make JavaScript Arrays support JSArray<any> instead of these changes that make the API harder to use?

[sigmundch]

is any exposed in any way that we can declare it today (for both dart2js and ddc)?

[srujzs]

I'm going to mark this as closed since the original issue has been addressed. Please feel free to reopen or open a separate issue if this can be cleaned up.

[mnordine]

I see this is closed and it was noted that the original issue has been addressed. Does that mean that the code above now returns the expected types?

e.g. Can I do:

import 'dart:html';

main()
{
  final devices = await window.navigator.mediaDevices.enumerateDevices();
  print(devices.first.runtimeType); // MediaDeviceInfo
  print(devices.first.deviceId);
}

[sigmundch]

@mnordine - I haven't verified this, but yes, I expect that the individual elements will contain the expected type.

final devices = await window.navigator.mediaDevices.enumerateDevices();
print(decices.runtimeType); // List<dynamic>
print(devices.first.runtimeType); // MediaDeviceInfo

because the list type is dynamic and not List<Object>, unfortuantely this means that you wont get a static error if you accidentally do:

devices.first.nonExistingProperty

You can however use the static type to avoid this problem:

MediaDeviceInfo device = devices.first;
print(device.deviceId);

Note that the fix landed in b84d6ba, which will be included in the next dev channel release of the sdk.

[mnordine]

Sorry if I'm misunderstanding, but was the solution here to make all web apis that return lists return them as List<dynamic>, therefore losing the typing?

If so, is this temporary?

Also, I don't understand how, if devices.runtimeType is List<dynamic>, a member of that list could be anything other than dynamic?

[sigmundch]

Sorry if I'm misunderstanding, but was the solution here to make all web apis that return lists return them as List<dynamic>

Correct, this was necessary because of how types are represented in the JavaScript program. When you create a list by hand in Dart, our compiler generates code that will store the type-argument together with that list. However, when the list is created outside the Dart program (e.g. from DOM APIs in the browser, or other JavaScript libraries), the list is a plain JavaScript arrays which is not tagged in any way.

An alternative approach is to wrap the lists to provide a different static type, but we have learned in the past that wrapping on every API call is expensive. Modifying the underlying JavaScript array to include our type-parameter tag is sometimes not safe (since it can affect the external JavaScript code in the case of JS-interop), but we should look more into whether this is possible in some cases like tehse.

For now, we adjusted the type to represent more closely what the browser is giving us: an untagged list, which today we interpret as a List<dynamic>

... therefore losing the typing?

This is unfortunate, yes. In the future, we are planning to have a different static type for this List<JsAny>, which helps us distinguish that this list doesn't contain instances of any type in Dart (dynamic), but possibly any type that could come from JavaScript/the browser.

Also, I don't understand how, if devices.runtimeType is List<dynamic>, a member of that list could be anything other than dynamic?

When we say List<dynamic> we are saying that the list is allowed to contain elements of any type. Similarly List<Object> would allow any instance that extends from Object, which again would include any type.

It so happens that we know from the browser that all instances in that list will be instances of MediaDeviceInfo. So if you were to wrap the list and cast it, e.g. using List.cast you could get a safer static type:

final devices = (await window.navigator.mediaDevices.enumerateDevices()).cast<MediaDeviceInfo>();
print(decices.runtimeType); // List<MediaDeviceInfo>
print(devices.first.runtimeType); // MediaDeviceInfo

(* this is the kind of wrapping operation that we could have added automatically, but we didn't to avoid the performance cost... it's not out of the question to reevaluate the tradeoffs and reconsider this)

[mnordine]

Appreciate the explanation and the cast tip.

we know from the browser that all instances in that list will be instances of MediaDeviceInfo

Given the above, why can't it be List<MediaDeviceInfo> then?

I think I understand you're saying you don't want users to pay the tax for adding the cast code for every call on those types. What I don't understand is how you're getting the types of the List elements themselves "from the browser"

[sigmundch]

What I don't understand is how you're getting the types of the List elements themselves "from the browser"

We use JavaScript's object.constructor.name to find the type associated with the object instance. In this case the constructor name for a single element in the list will be MediaDeviceInfo.

The list is different because the browser creates a list whose constructor name is simply Array, so just by looking at the instance we have no way of knowing which kind of lists it is. To associate the type as List<MediaDeviceInfo> we would need to either wrap/cast inside the API (as with the tip above) or add a way to attach the type information on the API boundary (this is not something that is supported today).

Hope this helps clarify things a bit.

[mnordine]

Makes sense, thx again