Custom Cards: Create a method that can import HA Elements to be used

[chaptergy]

The matter is discussed here: https://community.home-assistant.io/t/some-paper-components-broken-since-maybe-v0-115/228124

The gist is, styles are no longer properly loaded for custom cards and are only loaded once the component is used anywhere natively in home assistant. E.g. the paper-dropdown-menu is rendered as a list until you open a page where this component is natively used, afterwards (until you reload the page) it is rendered as a dropdown

[zsarnett]

What broke this for everyone in 0.115 is that we no longer always load every More Info Dialog element. We now Lazy Load them as we need them.

The potential solution (from @iantrich)

Create a way to import Home Assistant Frontend Elements that are in Core than can be used in Custom Cards. This will also require the frontend to list Breaking Changes to these elements in each major release.

---

Current workaround (from @thomasloven):

Load an element in HA that loads has these elements you need, for example:

<ha-slider> can be loaded in lovelace with

(await window.loadCardHelpers()).createRowElement({type: "input-number-entity"})

@thomasloven Uses this trick similarly here: https://github.com/thomasloven/lovelace-card-tools/blob/master/src/yaml.js

He also shows this example of loading these elements:

[bramkragten]

The potential solution will still cause breaking changes, as we will not keep all elements around or keep the API the same.

We could document changes in elements in the developers blog.

But the bigger issue with it is that we will loose a lot of our code splitting optimization and we will need a solution for that.

Adding all the elements as an dynamic import will make all elements a separate file, this means a lot more files need to be imported, a lot more, smaller chunks.

We should change our code splitting strategy if possible to allow them to be duplicated, both in our normal chunks and as a separate file for the dynamic import.

Webpack/rollup should only load the file if it isn't loaded before as we can't register the components multiple times, so that is an extra problem and not sure if that can be fixed.

[iantrich]

This becomes less of an issue as we move to mwc elements as a custom dev could just import the element from the lib if not already imported (I still like the idea of us packaging our elements as their own modules, much like mwc is distributed), except for elements that use mwc-ripple. Those appear to fail to load because we already have mwc-ripple defined as pointed out by neliss in chat. I feel like that is something we can figure out more easily.

The big downside to this approach is obviously the requirement bundling more into a custom card and applying themes to the vanilla mwc elements

[bramkragten]

@iantrich that won't work, or we would have to check for every import if the element is not defined already.

That is the big problem with custom elements, it will error when you try to define it twice. There are proposals to fix that, and I think that would be the real solution.

It would enable you to create your own custom element registry so you can overrule the global one.

[zsarnett]

We talked about this at length. The best solution so far is Thomas's workaround and exposing the Lovelace Create Element functions to the Custom Cards with the more info elements added.

A big issue that we could not find a good work around for is that The Custom Element Registry only allows the element to be registered once. so if HA Core registers and then a custom card tries to register the element as well (by importing the element from HA) then the card will error. And that goes the other way as well. More about that here: WICG/webcomponents#716

[ljmerza]

We talked about this at length. The best solution so far

What makes this the best solution? What other solutions were there talked about?

[zsarnett]

We talked about many solutions and most lead back to the Custom Element Registery not allowing the same element to be registered twice or making core much slower. Neither is a solution but more we talked about options that wouldn't work after thinking about the effects.

[zsarnett]

This was talked about with Bram, Ian, Thomas and myself. Thomas and Ian being big developers in the Custom card realm. So be assured we did try and talk about many solutions that ended back to the same place.

[ljmerza]

Okay that's fair. I know things can get stuck in the planning phase sometimes so let's get out of that and get this ball rolling. I want to either get this going or you can revert the lazy load commit allowing this to drag on forever but the fact is a number of custom cards are broken and seeing how this has been in the planning phase for a hot minute already let's at least get something going.