architecture
architecture copied to clipboard
Categories for config flow Integrations
Context
We're starting to see more and more integrations adopt config flows for setup and the list is already becoming intimidating when viewing it from the frontend.
Proposal
I think that we should consider adding context to our config flows so that the frontend can be better organized and not just show the ever growing list of integrations, but sort by categories, keywords and perhaps platform types.
Consequences
Existing config flow integrations would have to be updated as I can't think of a good automated migration strategy.
Any example of categories we would have? to expand on my question: eg ZHA integration, what category would that be?
but I agree, the list is too long now and search box helps if you know what you are looking for, but if you don't...
Just like on our site https://www.home-assistant.io/components/
A. That works for me
B. Out of curiosity I've tried to find ZHA platform, after staring for two minutes and trying: Others and HUB I failed to locate ZHA integration and caved to search for "Zigbee" which found it as IOT
class. And only after composing this message I found Zigbee under HUB
category. Apparently my attentions span is to low (:
I think that we should aim to get a single source of truth, and have that be synced between code and docs.
Potential filters
- DIY integrations
- Geo specific integrations (bus schedules in certain city)
- Voice/Sound integrations (some prefer silent setups or don't want speakers on their HA)
- No dependency integrations (where you don't need to buy a device to make it work)
I'm sure there are many others, but I think if correct categories/tagging can be setup and the current list is curated, there could be some sort of "profiles" that allow combining categories or excluding some.
For example, myself as a user, if I'm helping a friend that I know will never build himself a circuit or tinker with stuff that is not off the shelf, I'll exclude the DIY from his setup if possible, to simplify it for him so he can focus on things that are straight forward. Same with excluding geographical integrations that are not applicable for my location (ex. dublin_bus_transport
)
This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.
For that reason, I'm going to close this issue.
../Frenck