Windowscommunitytoolkit: Include WindowsStateTriggers in the project

[peterbozso]

I think that @dotMorten's WindowsStateTriggers library is a quite nicely crafted and useful one if you like working with XAML as much as I do. :)
My opinion is that (of course with the consent of the author) it'd fit nicely into this community toolkit. The maintenance would be easier and due to the popularity of the toolkit more people would be aware of and cloud leverage these very useful triggers.
What is your opinion on this @dotMorten?

[dotMorten]

@uruk It has definitely occurred to me a few times :-) After all I spend more time in this repo than in my old StateTriggers repo.

In hindsight some of them aren't great, or are encouraging what I since learned are poor practices, so
if we were to do this, I don't think all the triggers should be moved over. Especially the composite triggers are quite the mess.

[peterbozso]

Thanks for your response! :)
If the maintainers of this repo agree to merge the triggers too and you lay out some roadmap for the merge/rework, I'd be happy to help with it as much as I can in my free time.

[deltakosh]

Obviously we agree as long as it makes sense and simplify developer's life

[peterbozso]

Okay, very nice! :)
@dotMorten if you are still okay with the idea, just make a list of things to do so I can help with them!

[Odonno]

We still need that. :)

Will it be embedded inside the Toolkit?

[deltakosh]

ping @dotMorten

[Duranom]

Some of those and maybe a few other types would be a welcoming addition to the toolkit especially one where you can do AND / OR / XOR / NOR / NAND. Though perhaps having it provided as a separate nuget is handy in case you do not need all the special views like with simple B2B uwp apps, dowloading the main toolkit of course pulls the triggers one in by default.

Always annoying to remake them yourself because either hard to convince a party to use them because of few dow loads or last repo checkin was a long time ago.

[Odonno]

@dotMorten @deltakosh Can I try a PR? I don't think it is complicated so I would like to know if we are still ok to do this.

[dotMorten]

The And/or/xor/nor/nand ones are the ones I definitely don't think should be moved over. I get these are the most useful, but it is also the ones causing the most problems and confusion because they don't work with the platform ones. I'm still trying to push the Windows Platform team to add what's needed at a base level to enable these type of scenarios better (Hey reminder to @timheuer regarding raising a notification of IsActive changed state to enable composite scenarios ;-).

Another one that's problematic is the by-devicetype trigger, which encourages building by device rather than by device size, which is really bad practice. After that, there really isn't much left to move over, so that's why I've been a little hesitant :-(

[Odonno]

Yes, I see. But in some cases, it think it could be useful to be able to use DeviceFamilyStateTrigger and NetworkConnectionStateTrigger.

I don't think it will be used really often but I already used each of them once.

[Duranom]

The only problem with the composite trigger I had was that you cannot use any trigger inside of it as you need to implement ITriggerValue and thus wrap others, then again I always wondered why the UWP team never changed it to something like that or to require an abstract class. For more flexible implementation the whole interface would have to be removed and somehow check through code bind. With the philosophy of the toolkit content it would then become rather a hack-into trigger, though wondering if we will see any more proper implementation in the UWP Xaml as they come slow.

The devicefamily trigger is actually powerfull but depends on how used and can allow for some very interesting designs. While size of a device matters, I do think devices type matters as your experience on how things work really differ based on how you interact and can interact. (It is a different experience on a controller than with touch or mouse/keyboard)
Though you will still have the same concept of the design you relocate or change depending on the device and size in certain conditions, a simple example would be that on a mobile you want anything under 600 fully interactable and options a bit lower with vertical scrolling while on the other devices you want it to be an informing panel/experience with an expand option. When resizing to higher you want more on the screen and fully interaction on all. (and maybe if you target Xbox you might want it a bit different for the controller input experience).
The problems is that you need to use it in combination with something that handles And/Or and a more developed/complete continuum.

Really hope they will put in a lot of time and effort in the xaml and more in next redstone, so much potential still locked away for designers to go full nuts.

[gbarcho]

Whats the status? No activity in more than a year. Can we close it?

[michael-hawker]

I think having some StateTriggers in the toolkit would be a good idea, I see this and some Behaviors as a good set of things to be aware of in the future planning.

What we probably need is a good core list of a couple of the key triggers that everyone would need. One I'm aware of would be an AdaptiveStateTrigger that uses the parent's size instead of the whole Window.

Maybe that's a starting point. @dotMorten do you have any suggestions on a paired down list? Maybe we can use that to create a new issue with more actionable list of items and close this older one out?

[dotMorten]

I think these are probably among the more useful ones, however a few might not be needed now that we have much improved x:Bind support:

• NetworkConnectionStateTrigger
• EqualsStateTrigger
• IsNullOrEmptyStateTrigger
• NotEqualStateTrigger
• CompareStateTrigger
• InputTypeTrigger
• RegexStateTrigger

Of the ones I don't think we should do:

• DeviceFamilyStateTrigger (Against good practice, and we really only have Desktop these days)
  
  
  
  • IsTypePresentStateTrigger (there's a better way to do this in XAML now)
  
  
  • OrientationStateTrigger Couldn't think of a good scenario where this is useful. Use adaptive triggers instead.
  
  
  • IsTrueStateTrigger and IsFalseStateTrigger: Use EqualsStateTrigger or bind directly the IsActive property of the state trigger
  
  
  • CompositeStateTrigger This one is a mess and rely on custom implementation in a trigger. It would require a platform change in WinUI to expose events for IsActive before this should be introduced.
  
  

[dotMorten]

See #3030. That should give you something to start on...

[Kyaa-dost]

State triggers are part of Version 6.1.0 now. Thanks @dotMorten