-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
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>
i have no opinion |
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:
|
@sigmundch any updates on this request? |
Sorry, just catching up after being on PTO.
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:
|
lgtm |
Side note: even the JavaScript function |
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>
@sigmundch looks like this landed in https://dart-review.googlesource.com/c/sdk/+/273541, so we can close this? |
Yes, thanks for checking. |
@GZGavinZhao I took a look at your attemps, perhaps you should try passing an instance of your custom element: main.dart:
index.html:
|
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 bydart: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
andregisterElement2
APIs indart: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)
withjs_util.callMethod(document, "registerElement", args)
./cc @itsjustkevin @kevmoo @mit-mit @vsmenon
The text was updated successfully, but these errors were encountered: