PoC for allowing developers to control the defaults

[bijington]

Description of Change

This is not the typical approach to proposing change but I find it helps me to follow through with seeing the change and impact of that change.

This is an idea that I have had for a while but the recent Popup bug reports around CanBeDismissedByTappingOutsideOfPopup has prompted an investigation into feasibility. The proposal is to make it possible for developers to modify our Defaults classes through the Options class when initialising the toolkit. Therefore it keeps it relatively safe knowing that the defaults cannot change at runtime.

I have tried to group the defaults under feature specific classes to make it easier to navigate for a developer but I am keen to hear feedback on this.

I appreciate that it could be effort to add in all potential defaults but my thinking is to use this as an excuse to learn more about source generation and have that do the work that you see in the bulk of this PR. We could then place an attribute [ConfigurableDefault("FeatureName")] and let the magic happen.

It would then result in developers being able to call something like:

var builder = MauiApp.CreateBuilder()
    .UseMauiCommunityToolkit(static options =>
    {
        options.Defaults.Popup.SetCanBeDismissedByTappingOutsideOfPopup(false);

        options.Defaults.Popup.CanBeDismissedByTappingOutsideOfPopup = false;
    });

Thoughts?

Linked Issues

• Fixes #

PR Checklist

• Has a linked Issue, and the Issue has been approved(bug) or Championed (feature/proposal)
• Has tests (if omitted, state reason in description)
• Has samples (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Changes adhere to coding standard
• Documentation created or updated: https://github.com/MicrosoftDocs/CommunityToolkit/pulls

Additional information

[pictos]

this will apply to all popups and for entire lifecycle of the app? If so, I think this will not solve the problem totally, is normal to have popups with different configurations inside an application, that I said, I would say that forcing the same value for all popups aren't the best solution

[bijington]

I agree it won't solve all use cases and that isn't my intention here. The intention is to make it possible for developers to override the default values. It also doesn't need to be restricted to just Popups. This could reduce the friction for some developers entirely.

[TheCodeTraveler]

Let's first ensure the Defaults are documented and ensure developers how to modify the values and what the expected results should be.

We are still in the transition period for Popup where Developers are reporting "Issues" that are really just them asking questions about how to migrate their Popup v1 to Popup v2.

After developers have become accustomed to the new implementation of Popup v2, let's seek advice on ways we can improve it.

For example, there are already ways for developers to create a base class that overrides our defaults:

class PopupNoPadding : Popup
{
    public PopupNoPadding()
    {
        Padding = 0;
    }
}

[bijington]

For padding yes this is possible but not for things like CanBeDismissedByTappingOutsideOfPopup. Perhaps we can consider bringing back the ability to define that at the Popup level. Then developers could define a default style for the their popups if they wished too.

[TheCodeTraveler]

Fair point.

Personally, I'd like to encourage developers to use a View and subsequently deprecate the Popup class now that it is no longer required to show a Popup; this will help simplify the logic under the hood in PopupPage. That said, I wouldn't advocate to remove the Popup class until our .NET 11 release at the earliest. But let's chat about that in our next standup!

[pictos]

I agree it won't solve all use cases and that isn't my intention here. The intention is to make it possible for developers to override the default values. It also doesn't need to be restricted to just Popups. This could reduce the friction for some developers entirely.

People might want to customize the popup for each individual instance, which could lead to multiple APIs for customization in different locations and more code to manage.

One way to address this is to make the customization globally. I remember seeing something similar in the XF era, where styles were used to override values. We could modify the existing implementation to allow developers to customize the popup’s values using styles.

Here’s a sample: take a look at the calendar. Pay attention to the StyleClass. This allows developers to customize its values by overriding them using styles. For example, in here, developers define the StyleClass name as the same as the original control.

The values are applied through this property.

[bijington]

Fair point.

Personally, I'd like to encourage developers to use a View and subsequently deprecate the Popup class now that it is no longer required to show a Popup; this will help simplify the logic under the hood in PopupPage. That said, I wouldn't advocate to remove the Popup class until our .NET 11 release at the earliest. But let's chat about that in our next standup!

Although developers still need Popup in order to deal with returning values?

[TheCodeTraveler]

Although developers still need Popup in order to deal with returning values?

Not that I'm aware of. The return value is IPopupResult and developers can pass in their return values via Page.ClosePopupAsync() and PopupService.CloseAsync(). Is there something I've missed?

[bijington]

There's the scenario of having a Popup without a backing view model. Currently the Popup class has the ability to call close with a return value.

[VladislavAntonyuk]

Developers can create an instance with their default settings once and reuse it in their code. Setting some magic value through the whole app may lead to more issues rather then individual customization of each Popup.

[vouksh]

As a developer that uses popups, I would love to be able to set a few defaults at the application level. Our app is primarily used by people with motor control issues (tremor, jerkiness, etc), so I want to be able to just disable the "CanBeDismissedByTappingOutsideOfPopup" property application-wide, rather than needing to remember to either pass new PopupOptions { CanBeDismissedByTappingOutsideOfPopup = false } every single time or creating some reusable PopupOptions instance that may eventually have conflicts with future updates.

[TheCodeTraveler]

Closing in in favor of #2759