Frontend: 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: https://github.com/w3c/webcomponents/issues/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.

[zsarnett]

I think that it would be fair to revert the more info lazy load changes until 0.116 or until we implement the code for the changes

[ljmerza]

I was thinking in the next bugfix release. The next minor release won't be for a while. Kind of sucks to have all these cards broken right now.

[zsarnett]

Right. thats what I mean. Revert this now until the next 0.116 release or until we implement the other changes whatever comes last

[zsarnett]

https://github.com/home-assistant/frontend/pull/7123

[bramkragten]

It is now reverted in the just released 0.115.3

[iantrich]

7131

[koying]

@iantrich Am I correct assuming #7131 just reverts the revert of the lazy loading of the more-info?
Actually, as far as custom components go, going through the more-info (and the fact that it was working before) seems like a hack to me.

As far as I'm concerned, I'd like a way to import, e.g. @polymer/paper-dropdown-menu.
Importing, e.g., ha-paper-dropdown-menu is a plus (or a must depending on the implem)

[zsarnett]

@koying Did you read this issue at all? The issue is with Custom Element Registry not allowing duplicates. So if you register and then we register it. Something will break since it stops code from processing because of the error.

Once that issue is resolved upstream, then we want to be able to allow custom cards to import HA elements and even (I made this suggestion, idk if it would ever happen) create a separate repo for HA elements so they can be imported from there via NPM and installed and used

We would like to make it easier and less hacky but its not really possible. This is the best solution right now

[ljmerza]

create a separate repo for HA elements so they can be imported from there via NPM and installed and used

I like the idea of being able to load custom elements from within custom cards rather than separate npm libraries. Having to include the code for each custom element would bloat card's sizes.

[VDRainer]

Looks like 0.116 will break some custom-cards (including brams weather card) again.
I think a great improvement on this would be that custom-card developers, will get a message that something would break after a new HA release.
Beta testing is mostly made on the default UI and then there's a chance that more custom-cards are fixed on release day.
Maybe this should be possible over HACS?

[zsarnett]

There will be a dev blog post about this