SwitchPresenter Lazy Loading By Type

[michael-hawker]

Currently SwitchPresenter is great for a lot of small cases on frequently changing UI states (toggles, validation, etc...)

However, sometimes you want to load Pages or other heavier content for infrequent changes (signed-in vs. not-signed-in). If a user never signs in, why load the page instance and store it? (Even if it's not fully loaded into the VisualTree.)

Or you have an enum with various states, but only 1 or 2 of X may be valid for most cases.

In these cases, you may want to instead instantiate the content when it is needed instead of ahead of time. This can be hard to define in XAML directly with a SwitchPresenter, but can easily be encapsulated by another Page or Control.

What if instead of just taking XAML content directly, the SwitchPresenter could take a type instead?

    <controls:SwitchPresenter Value="{x:Bind ViewModel.CurrentState}">
      <controls:Case Value="NotSignedIn">
          <TextBlock Text="Please sign-in to use this feature."/>
      </controls:Case>
      <controls:Case Value="SignedIn" ContentType="UserSignedInPage"/>
    </controls:SwitchPresenter>

In the SignedIn case, the SwitchPresenter instead of setting the Content to our presenter in its logic here:

Windows/components/Primitives/src/SwitchPresenter/SwitchPresenter.cs

Lines 165 to 170 in 710c30f

	if (newcase != CurrentCase)
	{
	// If we don't have any cases or default, setting these to null is what we want to be blank again.
	Content = newcase?.Content;
	CurrentCase = newcase;
	}

Would detect that the ContentType property is set on the case and instantiate whatever that type is (UserControl, Page, etc...) and set it as the content, similar to frame navigation.

This way if the user never signs in, nothing else is ever loaded, we're just holding a reference to a Type as part of the Case definition.

Not sure if it makes sense to have another property on the SwitchPresenter or each Case to allow for caching the instantiated control so only ever one instance is created?

Anyway, seemed like an interesting extension/hybrid scenario that looks fairly straight-forward to add-on to the SwitchPresenter control.

[marcelwgn]

I really like this idea, this would allow for easier implementation of app navigation for example. While I don't think this will likely be a need, maybe allowing to also call a generator function (e.g. for setting up stuff before creating the control) would be also an option?

[michael-hawker]

Yeah, kind of like how the Lazy type works? Could be interesting, trying to think how that'd be specified in XAML though... Maybe it could be an event Loading? Then the value could be set on the event argument? Could do a few things like this, like this could be triggered first, and could be Handled to not set Content in the base SwitchPresenter code, you could then evaluate the ContentType property yourself, provide a cached value, whatever... 🤔

Don't think you'd want that to be runnable async (deferred) though, as that'd further delay loading which would kind of leave the UI in a 'blank' state. Think that'd be a different scenario, as if you have a complex thing you're loading you're probably toggling the SwitchPresenter on if it's loaded or not. This is more about just saving that initialization/memory overhead until it's absolutely needed as determined by your state.

[marcelwgn]

Something like the lazy type would be amazing but as you said having this work with XAML is probably not easy. Having an argument where you set the properties doesn't feel quite right to me since the SwitchPresenter then needs to wait for it to be processed. We could do something similar like the DataTemplateSelector interface and just have you implement a function (not async, 100% agree with you) that returns a UIElement. But maybe that feels to close the just using a DataTemplateSelector in the first place?

[michael-hawker]

Wondering how much of this would still be needed with the improvements in #550. Think there's still some need here, but maybe it can be a separate control now that just re-uses the same infrastructure?

[Arlodotexe]

This doesn't seem AoT safe

[michael-hawker]

Yup, good point. I was trying to think now if there was some better integration between XAML and Source Generators that could happen. Ultimately, this is a pattern that may just need to be in the platform to extend further with things like that.