Frontend: Add API on new Lovelace UI storage mode

[move[bot]]

@marklagendijk commented on Jan 5, 2019, 12:13 PM UTC:

Home Assistant release with the issue:
Home Assistant 0.84.

Component/platform:
Lovelace UI storage.

Description of problem:
In 0.84 a new storage mode for the Lovelace UI configuration was introduced.
This new storage mode works by storing the config in .storage/lovelace file which contains json.
The structure of this file is as follows:

{
    "data": {
        "config": {  },
    },
    "key": "lovelace",
    "version": 1
}

The config key contains an object with the actual Lovelace UI configuration (same as the contents of ui-lovelace.yaml).

Currently it is not clear if, and how custom components should modify the Lovelace UI configuration as stored by this new storage mode.
I would propose adding an API (that can be used by custom components) for reading / writing the configuration using this new storage mode.

Use case:
Use case the custom_updater component relies on being able to modify the Lovelace UI configuration.
Also see the discussion in this issue.

This issue was moved by cgarwood from home-assistant/home-assistant#19790.

[balloob]

We're currently in a feature freeze for Lovelace.

I also am not sure that is is something we should implement for managed mode, it gets very complicated very fast, and we need to support that forever. It means we need to add events to notify the frontend, frontend has to reload, even if user is just doing something, UI state is lost, etc. It also means people will start implementing logic via components instead of cards.

[Dinth]

@balloob you may be right here, but we (users) really need a working system of tracking and updating custom lovelace cards and components, like the one provided by tracker-card custom card. Without it, the whole system of custom cards will become a huge security hole and a source of bugs/problems in the future.

[balloob]

The problem is not our lack of API, the problem is the implementation of the custom card updater. This issue is here because the updater invalidates cache by appending a fingerprint of the file to the url. And the reason the file is getting cached, is because the custom card updater is abusing our local static storage to put content that is not static.

The custom card updater should consider adding their own HTTP API endpoint, which means you have full control over the HTTP headers and can cache when and how you want.