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

We need the ability to deregister or undefine custom elements. #970

Closed
johngamble opened this issue Sep 26, 2022 · 7 comments
Closed

We need the ability to deregister or undefine custom elements. #970

johngamble opened this issue Sep 26, 2022 · 7 comments

Comments

@johngamble
Copy link

There have been a couple of previous tickets created about this but they have been closed:
webcomponents/webcomponents.org#1294
#754

This is another use case which has not been brought up before, but an important one.

During unit tests, if we are unable to clean up and reset the browser state, then you break all future unit tests.

Please see my Stack Overflow post for a detailed explanation of the problem:
https://stackoverflow.com/questions/73849002/unit-tests-of-angular-elements-registered-with-the-customelementregistry-as-a-h

Custom elements are a very powerful feature, but not being able to write tests for using them really undermines their adoption.

@rniwa
Copy link
Collaborator

rniwa commented Sep 26, 2022

Why can't you create a new iframe for each unit test? That's exactly what I do in my own UI framework / library, and it works great.

@sashafirsov
Copy link

ability to de-register the custom element would allow to incrementally inherit currently registered element with own implementation which would use the original:

  • my-component is served by class MyComponent
  • taking the class from registry
  • register my-component-internal with MyComponent
  • unregister my-component and register class MyComponentFacade to same tag
  • use my-component-internal from overridden my-component-internal

there are zillions of use cases. From translation to analytics. Facade pattern is quite useful in general. Without unregistering the custom tag generic AOP approach would be difficult in Web Components world.

@caridy
Copy link

caridy commented Nov 18, 2022

sounds like a duplicated of #754

@rniwa
Copy link
Collaborator

rniwa commented Nov 18, 2022

Indeed. Closing as a duplicate of the issue #754

@rniwa rniwa closed this as completed Nov 18, 2022
@johngamble
Copy link
Author

Why close this issue if #754 has been closed? We need one of these tickets to be left open so it will actually be addressed?

@rniwa
Copy link
Collaborator

rniwa commented Nov 20, 2022

Please refer to #754 (comment) as how this issue can be re-opened.

@sashafirsov
Copy link

@rniwa , not here nor in #754 there is no clear criteria of reopening. The reference to the scoped element registry is orthogonal as it has same issue with undefining/redefining custom elements as global here.

Would be nice to answer on what could be the basis for issue reopening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants