New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve JS interop #35084

jmesserly opened this Issue Nov 7, 2018 · 0 comments


None yet
1 participant

jmesserly commented Nov 7, 2018

We'd like to significantly improve Dart's ability to interoperate with JavaScript libraries and vice versa. This will build on existing capabilities (see examples of current JS interop).

The new design will take advantage of Dart 2's sound static typing to provide JS interop that is convenient, high performance, and with minimal code size impact.

Some of the tasks for this:

  • Fully specify JS interop, including all details (#32929)
  • Fix incompatibilities between dart2js and dartdevc
  • Design it to optimize well in both dart web compilers
  • Implement static analysis (errors/warnings/hints) to help use it correctly, and prevent using unsupported patterns
  • Provide a convenient way of writing interface definitions (see firebase-dart for some examples--it's the best we can do with existing JS interop, but we can do better)
  • Implement tools for automatic interface generation (e.g. from typescript files, web IDL)

Some of the things we'll need to address (details are subject to change):

  • Dart APIs can be exported to JS (retain them during tree-shaking and ensure they're available from a consistent location)
  • Common Dart & JS types should interoperate well (e.g. Future/Promise, Iterables, Maps, Sets, JS Objects used as maps)
  • When necessary, wrappers and coercions will be implicitly done (i.e. no hand written boilerplate for doing those), possibly guided by annotations in the interface definition (e.g. an annotation to convert a parameter from a Map to a raw JS object)
  • Objects created in JS should be able to bypass Dart's reified generic checks (e.g. Arrays created in JS would not be subject to strict type checks, see #34195 for an example)
  • JS interop types should not be subject to runtime cast failures (similar to the "anonymous" types currently supported)
  • Ability to do JS dynamic dispatch distinct from Dart's dynamic (e.g. JSDynamic that dispatches directly to JS members)
  • Dart classes should be able to extend a JS interop class (e.g. for custom elements), and vice versa if possible (probably opt-in from the Dart class, so it explicitly exports itself for JS subclassing)
  • Ability to rename/hide JS APIs, including ones that start with "_"
  • "extension method" APIs can be added to JS interop classes (note: also includes getters/setters)
  • No metadata needs to be retained for JS types, and no RTTI needs to be computed at runtime

Other details:

  • Fix this binding for tearoffs (#32370)

Longer term: we'd like to use the new JS interop to implement the DOM in a package, and then migrate from "dart:html". This will necessarily be a slow migration/deprecation process, since "dart:html" is necessary for all web apps today. It may involve automated refactoring tools or opt-in static analysis to assist the migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment