[Feature] Custom StateTriggerBase to include an IsActive bool dependency property

[XAML-Knight]

Describe the problem this feature would solve

A few of our triggers use their own IsActive Dependency Property, and so it seems like refactoring the bool property (as useful as it is) into the parent base class (StateTriggerBase) would be in order.

Describe the solution

StateTriggerBase would be the proud new parent of a bool IsActive dependency property (and potentially also an OnActiveChanged event), which would then be inherited by any subsequent child classes.

Describe alternatives you've considered

Repeatedly adding the same boilerplate IsActive dependency property code to each trigger that needs it is not sustainable.

Additional context & Screenshots

Take a look at #1460

Hello, 'XAML-Knight! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[Arlodotexe]

Will need to name it something else to avoid confusing with the platform StateTriggerBase

[Arlodotexe]

Linking microsoft/microsoft-ui-xaml#1460

[Arlodotexe]

Should be noted that StateTrigger already exposes an IsActive dependency property, but it's marked as sealed. I'm curious to know what the intended usage was here...

[dotMorten]

StateTriggerBase isn't part of the community toolkit. The linked WinUI issue above is the correct one to comment on / vote up.

I'm curious to know what the intended usage was here...

The intended usage is that that is how you trigger that specific trigger - by setting it to true. It might have been more clear if it was called WhenTrueStageTrigger ;-)

[Arlodotexe]

StateTriggerBase isn't part of the community toolkit. The linked WinUI issue above is the correct one to comment on.

We're creating our own base class for the toolkit that has this property to reduce the copy-pasted boilerplate code for our own triggers, as described at the top of the issue.

When WinUI figures their side out, we'll revisit our version and update as needed.

[Arlodotexe]

The intended usage is that that is how you trigger that specific trigger - by setting it to true. It might have been more clear if it was called WhenTrueStageTrigger ;-)

That would make it publicly settable which I'm not sure is a good idea

I'm not entirely sure I understand the problem with allowing it to be publicly settable.
There are details to iron out, but letting devs override the state externally seems fine to me at first glance. Something I'm not seeing?

[dotMorten]

I'm not entirely sure I understand the problem with allowing it to be publicly settable.

For StateTrigger it is already publicly settable. For StateTriggerBase, that doesn't make sense, as there are other properties on its subclasses that you are meant to set in order to make it active/inactive. Take the adaptive trigger for instance: It is controlled by the view width, so what does it mean to also set the IsActive property? Will that override the width-based trigger? Which takes precedence?

[Arlodotexe]

For StateTrigger it is already publicly settable. For StateTriggerBase, that doesn't make sense, as there are other properties on its subclasses that you are meant to set in order to make it active/inactive. Take the adaptive trigger for instance: It is controlled by the view width, so what does it mean to also set the IsActive property? Will that override the width-based trigger? Which takes precedence?

These are the "details to iron out" I mentioned 🙂

Setting IsActive would act as a temporary override for the current state. When set, it would just call SetActive() interally.

However, the main point of exposing IsActive is to allow for reading when the trigger is active, and to allow for subscribing to state changes on individual triggers. Handling the setter behavior is secondary.

[michael-hawker]

I think the original intent and problem microsoft/microsoft-ui-xaml#1460 is describing is not around trying to override the IsActive state (if you need to do that just bind whatever to the vanilla StateTrigger) - It's about being able to monitor and understand when the state is set so you can potentially bind something else to it.

So, maybe this is a read-only DP that our own triggers can maintain the state in-sync with when they set the base SetActive call so that it can be tracked externally (if required).

Adding over-ride logic to each and every trigger we make seems a bit complex. I think that's what @dotMorten is trying to get at here.

[Arlodotexe]

Adding over-ride logic to each and every trigger we make seems a bit complex.

I don't think we need this at all, setting IsActive just activates or deactivates the trigger temporarily.

But thinking through the possible scenarios the setter could be used for -- making it readonly sounds good.

[dotMorten]

making it readonly sounds good.

Which is what my proposed design suggests. Subclasses like the StateTrigger can still add a setter to a read-only property.