#Prevent showing TODO and Calendar panels when not needed

1 messages · Page 1 of 1 (latest)

frigid jolt
#

I personally don't think 1) is viable in the beta

hardy forum
#

Maybe a stupid side question, can the frontend hide panels if there are no relevant entities

shy sorrel
#

Integrations may not work correctly if platforms are loaded but not the integration, that's not something we normally do.
That is incorrect, trigger and condition platforms are required to function without their integration loaded. That is part of their design.

frigid jolt
#

For what we've implemented, sure, but we don't know about custom stuff.

frigid jolt
shy sorrel
#

Reason for this is that those triggers and conditions may be needed by some other integration, so they are required to work correctly even if their integration is not loaded (yet).

shy sorrel
frigid jolt
#

Artur, the point of creating this thread was to ask others about input. Not that you should continue selling your idea.

shy sorrel
#

Sure, I agree, just want people to have a clear and accurate picture of benefits and drawbacks. The lack of support for services is absolutely a drawback of solution 1, "things may work incorrectly" isn't.

modest coyote
#

I don't understand this:

The frontend panel will be loaded if an integration which has a todo or frontend platform is loaded even though the integration doesn't load those platforms

hardy forum
#

the moment you add shopping list, it will appear

modest coyote
#

That's what the PR is solving as I understand it. I don't understand the quoted sentence though.

hardy forum
#

Oh right

#

I assume if you for example have an ESPHome or ZHA like setup, where if you only set up a contact sensor it doesn't setup everything from water heaters to sirens

#

They conditionally load platforms

shy sorrel
#

Exactly, async_process_integration_platforms isn't really meant to be used with entity platforms, it will import them unconditionally if the loaded integration has the platform file, even if the integration doesn't want to load it.

#

I think it's fine as a temporary solution to fix the issue, but not long term.

shy sorrel
#

Do we absolutely need these todo and calendar triggers to be always available? If the intention is to just make editing already existing ones possible, then here's a better alternative: https://github.com/home-assistant/core/pull/166911
This one should be merged either way, as it will work for all integrations, not just base platforms.

frigid jolt
frigid jolt
#

For reference, we've had problems previously with integration specific triggers requiring the integration + config entry to be loaded for the triggers to be able to be attached.

modest coyote
#

It's not required that triggers and conditions work without their integration loaded.

past lynx
#

Honestly, I think the calendar should only register the panel after the first calendar entity is added

shy sorrel
#

Which problem does this PR solve?
It solves the problem of trigger descriptions not being available to the frontend when a trigger is already being used, but the relevant integration is not loaded.

Who is ensuring this? Where is it documented it should work like that?
For reference, we've had problems previously with integration specific triggers requiring the integration + config entry to be loaded for the triggers to be able to be attached.
It's not required that triggers and conditions work without their integration loaded.
OK, I see there's a confusion regarding how trigger platform works and what are its requirements. Let me clarify.
It is required that all trigger platforms work without their integrations loaded. By "work" here it is meant that they are able to validate and initialise their triggers, off course it is likely that before the integration actually loads, no trigger will actually activate.
The reason it is a requirement is that other integrations are allowed to use the triggers. And those integrations can load before the integration that provides the trigger.
That is why the API is constructed the way it is. When you call async_validate_trigger_config the trigger platform of that trigger is loaded, but not the integration itself.
So both the specification of the system and the API shape already enforce this requirement. If some trigger platform doesn't follow it, it is already broken.

frigid jolt
#

Yes, but as I mentioned we had problems where integrations didn't expect async_validate_trigger_config to be called on them before the config entry was loaded. We can't change the behavior again the day before release.

shy sorrel
#

This is already the behaviour we enforce due to how the API works.

#

If integration X uses trigger from integration Y, and loads before it, it will fully expect the trigger platform of Y to load correctly.

frigid jolt
#

hmm, is that how it works? it's been too long since I messed with the fundamentals of the trigger loading

shy sorrel
#

Yes, that is how it works. 🙂
If you look at my last PR I'm not adding any loading there, the platform is already loaded.

frigid jolt
#

i should remember this, because I wrote the stupid code 🙁

#

But you've improved it since of course 😛

#

But, can we try to first focus on doing something realistic for the release tomorrow so the users don't see the stupid panels? I think the lowest risk and least hacky would be to either merge one of my PRs from yesterday, or just remove calendar and todo from always-loaded integrations.

shy sorrel
frigid jolt
#

can you make a variant of that for conditions too?

#

but your PR doesn't really solve the issue with editing. if an automation is disabled, the loading doesn't happen, right?

shy sorrel
modest coyote
modest coyote
frigid jolt
#

Yes, sure, it's OK.

#

I'll close mine and open a PR which removed calendar + todo from always loaded integrations