Skip to content
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

[dart:html] Breaking change: delete registerElement* APIs in dart:html #49536

Closed
sigmundch opened this issue Jul 27, 2022 · 10 comments
Closed

[dart:html] Breaking change: delete registerElement* APIs in dart:html #49536

sigmundch opened this issue Jul 27, 2022 · 10 comments
Assignees
Labels
area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. breaking-change-approved web-libraries Issues impacting dart:html, etc., libraries

Comments

@sigmundch
Copy link
Member

Long ago dart:html provided methods to access the custom elements API of Web Components based on the specification version 0.5. Since then, the custom element API has changed a lot and today's browsers no longer support the API exposed by dart:html - those APIs are now outdated and simply fail at runtime.

Several years ago we also made the decision to not expose the latest custom elements API through dart:html, but instead encourage using JSInterop to leverage web components directly.

The intent of this breaking change is to remove the broken registerElement and registerElement2 APIs in dart:html. Note that APIs to access shadow dom, template elements, and other features that are part of the web component umbrella are not affected by this breaking change request.

What can break?

These APIs are already broken, but provide errors at runtime. Removing the APIs may potentially introduce compile-time errors.

Some users may not have errors at runtime if they relied on loading the Web Components v0.5 polyfill on all browsers. This polyfill is available on a couple channels, one of which is our web_components package. We think the use of this polyfill is not common (for instance, the web_component package hasn't been updated in 5 years, and is not even compatible with Dart 2.0). So it seems unlikely that developers in our community rely on it.

Mitigation
Calls to the removed APIs need to be removed. In the rare scenario that a developer is using the polyfill, they will still be able to use it through JSInterop. They can do so by replacing document.registerElement(args) with js_util.callMethod(document, "registerElement", args).

/cc @itsjustkevin @kevmoo @mit-mit @vsmenon

@sigmundch sigmundch added web-libraries Issues impacting dart:html, etc., libraries breaking-change-request This tracks requests for feedback on breaking changes area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. labels Jul 27, 2022
@sigmundch sigmundch self-assigned this Jul 27, 2022
copybara-service bot pushed a commit that referenced this issue Jul 28, 2022
The `registerElement` APIs in `dart:html` are legacy APIs based on a
deprecated Web Components v0.5 specification. These methods don't work
on modern browsers and can only be used with a polyfill.

The latest Web Components specification is supported indirectly via
JSInterop and doesn't have an explicit API in the `dart:html` library.

This change marks these APIs as deprecated. We intend to remove them in
the future (see #49536)

Fixes #48973

Change-Id: I2e96d36e95c9971b59cde80bc4da49b63d12b17c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252840
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
@itsjustkevin
Copy link
Contributor

@vsmenon @grouma @Hixie

@Hixie
Copy link
Contributor

Hixie commented Jul 29, 2022

i have no opinion

@grouma
Copy link
Member

grouma commented Aug 1, 2022

Is there a reason we want to encourage JS interop usage instead of fixing the APIs?

As for the extent of this breaking change, I couldn't find any usages in Google3 besides this SDK test:

document.registerElement("foo-tag", a.a);

@itsjustkevin
Copy link
Contributor

@sigmundch any updates on this request?

@sigmundch
Copy link
Member Author

Sorry, just catching up after being on PTO.

Is there a reason we want to encourage JS interop usage instead of fixing the APIs?

Note that the web components API changed substantially, so even if we wanted to expose the latest API, it would not longer match the API we are proposing to delete on this issue, so we'd have to go through this breaking change regardless.

That said, the are a couple reasons to go via JSInterop:

  • Webcomponents are heavily JavaScript centric. Registering custom elements ask that you extend from native DOM types directly and properly plumb the underlying JavaScript constructors to some of the custom element APIs. As a result, these APIs don't just involve a library, but also rope in changes in our compilers to properly model these types and to intertwine Dart and JavaScript semantics for these classes. Our experience implementing that for v 0.5 in dart2js was that this added a lot of complexity in our compiler, and unfortunately it's not easy to just reuse what we have to evolve it to the new web components standard.
  • We are also evolving to make dart:html based on JSInterop. We are moving towards a direction where Dart doesn't couple the browser APIs in its libraries, but instead gives you a powerful interop layer that allows you to access whatever the browser environment provides.

@vsmenon
Copy link
Member

vsmenon commented Aug 16, 2022

lgtm

@itsjustkevin itsjustkevin added breaking-change-approved and removed breaking-change-request This tracks requests for feedback on breaking changes labels Aug 16, 2022
@GZGavinZhao
Copy link

GZGavinZhao commented Aug 18, 2022

Side note: even the JavaScript function Document.registerElement() is deprecated in favor of customElements.define(), which itself doesn't seem to work either (at least in my attempts) potentially without #13836.

copybara-service bot pushed a commit that referenced this issue Sep 20, 2022
Registering custom elements are already broken -- see: #49536. There are plans on deleting this code at some point. This current change cleans up dynamic invocations in the deprecated code.

Removes cruft on already-deprecated code and doing it now because I assume dynamic clean up will finish before the issue resolves.

Change-Id: Ic6250c139c5d9b08d88650110f55442a7bf5dd42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259247
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
@mit-mit
Copy link
Member

mit-mit commented Dec 12, 2022

@sigmundch looks like this landed in https://dart-review.googlesource.com/c/sdk/+/273541, so we can close this?

@sigmundch
Copy link
Member Author

Yes, thanks for checking.

@jksevend
Copy link

jksevend commented Jul 9, 2023

@GZGavinZhao I took a look at your attemps, perhaps you should try passing an instance of your custom element:

main.dart:

class NameInfoElement extends HtmlElement {
  static final tag = 'name-info';
  NameInfoElement.created() : super.created();
}

void main() {
  window.customElements?.define(NameInfoElement.tag, NameInfoElement.created());
}

index.html:

<!DOCTYPE html>

<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="scaffolded-by" content="https://github.com/dart-lang/sdk">
    <title>dart_wc</title>
    <link rel="stylesheet" href="styles.css">
    <script defer src="main.dart.js"></script>
</head>

<body>

<name-info>Ja moin</name-info>

</body>
</html>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-web Use area-web for Dart web related issues, including the DDC and dart2js compilers and JS interop. breaking-change-approved web-libraries Issues impacting dart:html, etc., libraries
Projects
None yet
Development

No branches or pull requests

8 participants