card-mod support

[FrnchFrgg]

Currently, plotly-graph is not compatible with card-mod. I think there are two ways of making it compatible. A way which will work only with card-mod, and another which should make plotly-graph sufficiently similar to a vanilla card that card-mod and any other similar mod will work.

The first way is to call some card-mod primitive yourself so that it can do its magic. See https://github.com/thomasloven/lovelace-card-mod/blob/master/README-developers.md where AFAICT el should be the <ha-card/>, type should be what you want it to be (probably plotly-graph but you can use card which is what card-mod uses when it can hook into the ha-card itself as in the complicated method), styles should be config?.card_mod?.style || config?.style || "" where config is the whole card configuration, variables should be { config }, the unused should be null, and the last one I think should be false.

See https://github.com/thomasloven/lovelace-card-mod/blob/master/src/patch/ha-card.ts#L25 which is what card-mod wants ha-card to do when it is patched. I do not know if and when you are supposed to use the returned object to call its refresh() method as the patched ha-card does.

The other way is to make plotly-card extend LitElement instead of HTMLElement, as apexcharts-card does here: https://github.com/RomRider/apexcharts-card/blob/master/src/apexcharts-card.ts#L116. Another much simpler example to get inspiration from is https://github.com/thomasloven/lovelace-card-mod/blob/master/src/mod-card.ts whose role is only to wrap elements without an inner <ha-card/> into one.

But maybe the only thing that makes a LitElement work as-is with card-mod and your HTMLElement-based card not is that you do not provide any update() method ? Maybe adding a dummy update() would magically make things work ? I'll have to try if you do not get to do it before me.

Note that I never programmed in TypeScript before so I am very slow and naive. Sorry for that.

[FrnchFrgg]

In fact, I would bet on just providing a dummy update() method for card-mod to patch because its setConfig hack works so it can find your own setConfig(). The proof is that when changing the configuration while editing the card makes the card-mod settings apply.

Playing in the debugger hints to me that providing an update() method is not enough since it is never called (it seems LitElement does that as part of its lifecycle handling). But maybe is
would work to provide a dummy update() and call it from a setTimeout so that it is called at least once.

[dbuezas]

I never programmed in TypeScript

If you are not doing it already, do try vscode! It gives you autocomplete, marks errors, etc. It guides you! :)

so I am very slow and naive

You forgot curious and persistent! It's the same for me in python btw.
And yet you contributed to this repo with a cool, non-trivial feature 😎 👏

In any case, I think you are right. It looks like card-mod patches the ha-card by replacing (and wrapping) its firstUpdated method. When firstUpdated gets called, the patch looks for the shadow DOM parent (this is the plotly element!) and then replaces its setConfig function with yet another wrapper. Finally, when setConfig is called card-mod patches the update function if available. A fairly elaborate hack.
I'm reading that here:

I am not quite sure why card-mod works while editing the card, HA will call setConfig, but card-mod doesn't refresh when that happens 🤷. Also, afaik, HTMLElement doesn't have an update function. Maybe HA adds all of that.

Anyway, I think the solution involves calling this.update() ourselves
This should make card-mod work.

I don't use card-mod so I can't test it myself (slash I couldn't be arsed to), but I made a branch you can try :)
master...fix/card-mod-support

[FrnchFrgg]

Your fix is not enough. I tried quickly with the dev version of plotly-graph to see what causes the problem but had not enough time to dive deep. Maybe that's just because setConfig() is called too soon (before the ha-card is created and thus the setConfig() gets patched) ? When editing, each change means a call to setConfig() and that makes the thing work.

In fact, it seems that card-mod works (since it attaches its <style/> placeholders) but does not see its configuration (the placeholders are empty). As it searches for it in the ha-card ancestors config attribute, maybe your setConfig(), while called too soon for the patched version to kick in, is called too late for the config attribute to be filled when card-mod sets itself up in the ha-card ?

Tomorrow I'll check the ordering of the method calls by HA, then try to call setConfig() again with a setTimeout(). Sadly, to be able to put a breakpoint at the right place I need to use the development version of card-mod (so that the Firefox debugger sees the TypeScript files and links them to the Javascript it runs).

[dbuezas]

Oh, you are right, card-mod is looking for the ha-card element, and that one is added later on connectedCallback.

[dbuezas]

I think setting the html can be done in the constructor already, and initialisation can happen on connectedCallback, then it should work.
Then the dummy updated function may be unnecessary too

[dbuezas]

Or maybe the whole HTMLElement should ve an ha-card?

[dbuezas]

The fix/card-mod-support has the change, let me know if this works.
If it doesn't, I'll read the update function, but I think this is only necessary when making bigger html changes.

[FrnchFrgg]

This is still not working. The ordering of calls is 1) constructor 2) unpatched setConfig 3) connect [setConfig is still unpatched] 4) disconnect 5) connect [again setConfig unpatched].

If I add window.setTimeout(() => this.setConfig(config), 100); at the top of setConfig (guarded by a test whether it is patched or not to avoid repeating ad nauseam) then the first delayed setConfig is patched, and card-mod works.

[FrnchFrgg]

Note that card-mod would work if you saved the config argument to setConfig into this.config instead of saving the parsed one. The real problem is that card-mod finds the config with this method: https://github.com/thomasloven/lovelace-card-mod/blob/06140ff020e94a20f7eec9f51c18ad04aef0e8f1/src/helpers.ts#L121

And you do not save the original config where it looks. Maybe you should save the original config in this.config and use this._config for the parsed one ? Or another name altogether. Just saving the original config in this._config is not going to work due to the lookup ordering.

[dbuezas]

Oh that would be enough? So i can undo the rest? That's easy. I could also copy whatever alien properties to my parsed one, it's one line

[FrnchFrgg]

Indeed, I just tested on master and simply replacing

    const newConfig: Config = {

by

    const newConfig: Config = {
      ...config,

in setConfig() does the trick. It would have an unintended effect though: the variables accessible in the card-mod style template would be the interpreted config, not the raw one. It may confuse some people to get your defaults in some of them instead of just what they actually put in the card YAML. Probably nothing to fuss about though. YMMV.

[dbuezas]

Oh yes, that's exactly what I meant. But you are right with the caveat.
If you want, feel free to make a PR, just right click, rename symbol, and then you can store the original config in the instance.