Cleaning up (undefining) custom elements?

[trusktr]

I notice many web-based libs/APIs focus on creation without reciprocal destruction mechanisms. They assume that cleanup happens when the "web page" is closed.

A long running, wanting-to-be-robust, web application might like to unload elements if it knows they are not being used on the page any more (f.e. it switched to another client-side route). It may like to lose references to classes, and can fetch the relevant JS (cached) later.

Would it make sense to be able to unregister elements, to free up memory?

[domenic]

It may. What we'd want to see before committing to this sort of work is memory profiles of popular custom element-using sites, showing that a large portion of their memory usage comes from no-longer-used custom element definitions. Are you interested in collecting such evidence?

[trusktr]

I'm interested, but not sure how to find the sites. They should have many client-side routes that load route-specific JS which includes new elements for the route. At some point my own site will do that.

[caridy]

In my experience, with one of the heaviest components ecosystems that I know of, the component's registry is never the bottle neck, not even close. On top of that, this seems like a lot of work for so little reward. What if the component itself kicks in some services that will eventually attempt to create instances of itself? Who is in charge?

[annevk]

Closing, happy to reopen once there's a clearer demonstration this can be useful.

[mbostock]

The fact that custom elements can’t be redefined essentially makes them unusable within Observable’s reactive notebook environment. Our runtime is predicated on being able to re-evaluate cells whenever either the code in a cell changes, or a value it references changes. So, you can’t really use custom elements within Observable, because every time you change the code, you can’t cleanup the old definition before you re-evaluate the cell.

[stevenvachon]

Redefining custom elements is also useful for:

• Hot Module Replacement (HMR).
• Unit testing without page refreshes.

[mattsteve]

@annevk Please reopen. It's silly to have an irreversible process.

[annevk]

I think #754 (comment) clearly states what is needed, no?

[stevenvachon]

@annevk I think that comment is less relevant now, given the later comments.

[rniwa]

Wouldn't most of use cases here be addressed by #716?

[mattsteve]

@annevk Look at mbostock and stevenvachon's comments. Our concern isn't about freeing up memory, it's about the ability to replace a custom element after it's already been defined.

[mattsteve]

And think realistically about what actually happens on a website. Many websites use vendor Javascript and sometimes vendors do things that collide with the main functionality of the page. In enterprises, a developer may not have a choice to use a different vendor as it is decided by the business. Having the ability to work around misguided code is invaluable for Javascript.

[stevenvachon]

@rniwa Scoped custom elements are a partial solution, but still not when testing the default registry.