-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
Historically, it was common for users to treat JS values through interop as Dart types and not JS types, mainly because the concept of "JS types" did not exist yet. So, values may flow through as Object or dynamic to other parts of code. This code may accept both a Dart and a JS value, making it difficult to determine how to treat such a value without some way of distinguishing the two runtimes.
The canonical way to type-check Dart objects is to use is, but we don't want users using that if it's a JS value, as it may give inconsistent values. This is partially why we have the invalid_runtime_check_with_js_interop_types lint.
The canonical way to type-check JS values is to use isA, but that requires a cast to JSAny in the first place. This cast will always succeed when compiling to JS (because it's Object under-the-hood there), but may fail when compiling to Wasm (because it's JSValue). This is our best option today.
So, to determine how to type-check a given Object, it is useful to know whether it's a JS value in the first place. One such mechanism is a compiler-specific external patched API in dart:js_interop.
Some quirks that we might come across:
- Primitive types (
String,int/double/num,bool) are both Dart and JS values when compiling to JS. This is not true when compiling to Wasm. We may want to always treat them as JS values for the sake of this API, but users should be aware that they should still type-check for the Dart primitive types when this API returns false so that they handle the Wasm case correctly. - Dart functions are JS functions in DDC, so the implementation should use the type system internals to differentiate them instead of interop.
- Inconsistencies in our internal type system checks. Hopefully this should be fine in most realistic use cases, but we've seen edge-cases before e.g. DDC treating prototypes of compiled Dart objects as Dart objects whereas dart2js and dart2wasm do not. I expect dart2wasm should generally have no issues with this check due to the boxing.
- We may want to modify the
invalid_runtime_check_with_js_interop_typescheck to account for this new API e.g. pointing users to this API when they do ais JSAnycheck.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status