Continued: Popup V2 does not allow any way of passing data to a popup anymore if you are not using Shell

[LeoJHarris]

Continuing discussions off the back of this issue #2693 since it was closed but feel like there is some confusion around the new V2 Popups, at least for me.

So prior to the new V2 Popups I was previously doing something like this:

popupService.ShowPopup<ProgressPopupViewModel>(onPresenting: async progressViewModel =>
 {
     // Sets a BindableProperty for the progress popup's label
     progressViewModel.ProgressText = localizationResourceManager.GetValue("LoggingInText");

     // My Long running Task here when the Progress Popup is showing

     // Closes the Popup when Task is completed above
     progressViewModel.CloseCommand.Execute(default); 
 });

Having spent time now looking at how to migrate the above to V2 Popups I don't see a way that the plugin supports it very well in the same manner as before since overload methods for ShowPopupAsync require Shell when providing shellParameters.

That being said however I've introduced a property called ProgressFunc that I would like to assigned at the time I push the popup i.e.

public partial class ProgressPopupViewModel : ObservableObject
{
    public Func<Task>? ProgressFunc;

    [ObservableProperty]
    private string _progressText = string.Empty;
}

Follows this example: https://github.com/CommunityToolkit/Maui/blob/main/samples/CommunityToolkit.Maui.Sample/Views/Popups/UpdatingPopup.xaml.cs for how I call it.

Opened += async (_, _) =>
{
    if (progressPopupViewModel.ProgressFunc is not null)
    {
        await progressPopupViewModel.ProgressFunc().ConfigureAwait(false);
    }
};

Ideally if I can set ProgressFunc at the time the Popup is pushed then I could call the Func when the Popup is opened which would behave fairly similar to how it this did in V1 Popups.

I suppose the question for me becomes, assuming I have the right approach, what will the following look like so ProgressFunc and ProgressText can be assigned at the time the Popup is showing? Since the ViewModel is not immediately available anymore like it once was:

IPopupResult popupResult = await popupService.ShowPopupAsync<ProgressPopupViewModel>().ConfigureAwait(true);

Since this is not a Shell App the IQueryAttributable is not available and V2 seems like a step backwards for apps for following MVVM patterns like our is.

Would be nice to get some further guidance on these breaking changes for use cases like ours as we try navigate around these changes. Thanks!

[stephenquan]

Because Popup inherits from View you can now set BindingContext on the Popup. e.g.

using CommunityToolkit.Maui.Extensions;
using CommunityToolkit.Maui.Markup;
using CommunityToolkit.Maui.Views;
using CommunityToolkit.Mvvm.ComponentModel;

// ...

public async Task ShowPopup()
{
    var popup = new Popup();
    popup.BindingContext = new ProgressPopupViewModel() { ProgressText = $"LoggingInText" };
    popup.BackgroundColor = Colors.Green;
    popup.Content = new VerticalStackLayout
    {
        Children =
        {
            new Label { TextColor = Colors.White }.Bind(Label.TextProperty, static (ProgressPopupViewModel ctx) => ctx.ProgressText),
            new Button { Text = "Close", Command = new Command(async () => { await popup.CloseAsync(); }) }
        }
    };
    popup.Opened += Popup_Opened;
    await this.ShowPopupAsync(popup);
}

private async void Popup_Opened(object? sender, EventArgs e)
{
    await Task.Delay(1000); // simulate a progress delay
    if (sender is Popup popup && popup.BindingContext is ProgressPopupViewModel viewModel)
    {
        viewModel.ProgressText = "Opened";
    }
}

N.B. I noticed you're still using the older MVVM syntax. Check out the blog https://devblogs.microsoft.com/dotnet/announcing-the-dotnet-community-toolkit-840/ and the corresponding new syntax (which has compiled-bindings, xmldoc advantages):

[ObservableProperty]
public string ProgressText { get; set; } = string.Empty;

[Skarzag]

I'm stuck in the same situation.
The new Popup implementation is missing a crucial point : not everyone use Shell :p

My previous implementation was working like a charm... :(

public async Task<TReturn> ShowPopupAsync<TViewModel, TInit, TReturn>(TInit initData)
      where TViewModel : IReturnablePopupViewModel<TInit, TReturn>
      where TInit : notnull
      where TReturn : notnull
  {
      var ct = new CancellationToken();

      var returnedPopupData = await _popupService.ShowPopupAsync<TViewModel>(onPresenting: vm => vm.Init(initData), ct);

      if (returnedPopupData == null)
          return default;

      if (returnedPopupData is TReturn returnedData)
          return returnedData;
      else
          throw new InvalidDataException();
  }
  
  public interface IReturnablePopupViewModel<TInit, TReturn> : INotifyPropertyChanged, INotifyPropertyChanging
   where TInit : notnull where TReturn : notnull
{
    event EventHandler<TReturn> OnCloseReturnDataEvent;
    void Init(TInit initData);
}

Hope there will be some new ways to handle this problem... i can't bump CommunityToolkit version anymore.

[TheCodeTraveler]

There are many ways to pass data into your Popup, using PopupService + Dependency Injection, using DataBinding, using ViewModels, using Messaging Services, subscribing to events like Popup.Opened Popup.Closed View.Loaded, View.Unloaded, View.ChildAdded, View.PropertyChanged, etc.

Popup is now just a View and should be thought of and implemented like any other View in .NET MAUI. For example, you will pass data into Popup the same way you would pass data into another ContentPage, Button, Label, etc.

[belmonmi]

I'm encountering a similar issue. Without using Shell, there currently appears to be no straightforward way to pass data to a popup's ViewModel via IPopupService. What’s needed is an equivalent method to:

void ShowPopup<T>(Shell shell, IPopupOptions? options = null, IDictionary<string, object>? shellParameters = null)

—but one that accepts INavigation or Page as an argument instead of Shell. Alternatively, it would be helpful if the onPresenting callback provided access to the navigation context (INavigation or Page) when using non-Shell navigation.

While using IQueryAttributable is a solid and standardized approach for passing data—and we recognize the benefits of adopting it for future development—it does introduce challenges for existing applications. We have production apps that rely on previously tested functionality, and retrofitting multiple ViewModels to support this new pattern would require significant changes and a full testing cycle.

Since the Community Toolkit is such a critical part of the .NET MAUI ecosystem, we would appreciate a more gradual or backward-compatible approach to breaking changes. One potential solution could be adopting a "Versioning Design Pattern" that provides continuity for legacy implementations while supporting new paradigms.

Thank you for your hard work and for considering this feedback.

Best regards,
Michael

[TheCodeTraveler]

There are many ways to pass data into your Popup, using PopupService + Dependency Injection, using DataBinding, using ViewModels, using Messaging Services, subscribing to events like Popup.Opened Popup.Closed View.Loaded, View.Unloaded, View.ChildAdded, View.PropertyChanged etc.

Popup is now just a View and should be thought of and implemented like any other View in .NET MAUI. For example, you will pass data into Popup the same way you would pass data into another ContentPage, Button, Label, etc.

[LeoJHarris]

@belmonmi I feel like this is definitely is lost functionality and became a significant breaking change in a core library.

Instead of refactoring many call sites across our application, we chose to re-create the missing abstraction so the usages could be left intact, maybe it will help you or require tweaking to fit.

Extension Method Wrapping Popup V2 API's

public static class PopupServiceExtensions
{
    public static async Task<TResult?> ShowPopupAsync<TViewModel, TResult>(
    this IPopupService popupService,
    INavigation navigation,
    Action<TViewModel> onPresenting,
    PopupOptions? popupOptions = null,
    CancellationToken token = default) where TViewModel : class, IPopupConfigurableResultViewModel<TResult>
    {
        ArgumentNullException.ThrowIfNull(navigation);
        ArgumentNullException.ThrowIfNull(onPresenting);
        token.ThrowIfCancellationRequested();

        popupOptions ??= new PopupOptions
        {
            Shape = new RoundRectangle
            {
                CornerRadius = new CornerRadius(20),
                StrokeThickness = 0,
            }
        };

        var mauiContext = Application.Current?.Handler?.MauiContext;
        if (mauiContext is null)
        {
            throw new InvalidOperationException("MauiContext is not available.");
        }

        var services = mauiContext.Services;
        var viewModel = services.GetRequiredService<TViewModel>();
        onPresenting(viewModel); // Execute the presenting logic

        if (!PopupViewModelMappings.ViewModelToPopup.TryGetValue(typeof(TViewModel), out var popupViewType))
        {
            throw new InvalidOperationException($"No Popup View registered for ViewModel type {typeof(TViewModel).FullName}. Ensure AddPopup<TView, TViewModel> was used in MauiProgram.cs.");
        }

        if (services.GetRequiredService(popupViewType) is not CommunityToolkit.Maui.Views.Popup popupView)
        {
            throw new InvalidOperationException($"No Popup View instance found for type {popupViewType.FullName}. Verify DI registration.");
        }

        popupView.BindingContext = viewModel;

        var app = Application.Current;
        var mainWindow = app?.Windows.Count > 0 ? app.Windows[0] : null;
        if (mainWindow is null)
        {
            throw new InvalidOperationException("No main window found.");
        }

        // Use a TaskCompletionSource to signal when ModalPushed has truly completed for this popup
        var modalPushedCompletionSource = new TaskCompletionSource<bool>();

        void ModalPushedHandler(object? sender, ModalPushedEventArgs e)
        {
            // Only set the ViewModel if it's the popup we just presented

            ViewModelLocator.SetAutowireViewModel(e.Modal, ViewModelLocatorBehavior.Forced);
            modalPushedCompletionSource.TrySetResult(true); // Signal completion
        }

        mainWindow.ModalPushed += ModalPushedHandler;

        TResult? finalResult = default;
        try
        {
            // Start showing the popup
            var uiShowTask = navigation.ShowPopupAsync(popupView, popupOptions, token);

            // Wait for the ModalPushed event to fire for *this specific popup* before proceeding,
            // or for the UI show task to complete if ModalPushed isn't critical for initial state
            //  ViewModelLocator.SetAutowireViewModel MUST run before any popup logic.
            await modalPushedCompletionSource.Task;

            // Now, wait for either the ViewModel to complete or the UI to be dismissed by the user
            var viewModelResultTask = viewModel.PopupResultCompletionSource.Task;
            var completedTask = await Task.WhenAny(viewModelResultTask, uiShowTask); // uiShowTask completes on dismissal

            if (completedTask == viewModelResultTask)
            {
                // ViewModel completed first, get its result
                finalResult = await viewModelResultTask;
                // Now, explicitly close the UI popup, only if it's still open
                if (popupView.Handler != null && popupView.Handler.PlatformView != null) // Check if the popup is still active
                {
                    // Small delay can help ensure UI is ready for dismissal on iOS, if needed.
                    // await Task.Delay(50);
                    try { await popupService.ClosePopupAsync(navigation, token); } catch { }
                }
            }
            else // completedTask == uiShowTask
            {
                // UI dismissed first (e.g., user tapped outside or another navigation happened)
                // Ensure ViewModel's task is completed (e.g., with a default/canceled result)
                if (!viewModel.PopupResultCompletionSource.Task.IsCompleted)
                {
                    viewModel.PopupResultCompletionSource.TrySetResult(default);
                }

                finalResult = default; // Or null, depending on your default
            }
        }
        catch (OperationCanceledException)
        {
            if (!viewModel.PopupResultCompletionSource.Task.IsCompleted)
            {
                viewModel.PopupResultCompletionSource.TrySetCanceled(token);
            }
            // Only attempt to close if the popup is still "there"
            if (popupView.Handler != null && popupView.Handler.PlatformView != null)
            {
                try { await popupService.ClosePopupAsync(navigation, token); } catch { }
            }

            throw;
        }
        catch (Exception ex)
        {
            if (!viewModel.PopupResultCompletionSource.Task.IsCompleted)
            {
                viewModel.PopupResultCompletionSource.TrySetException(ex);
            }
            // Only attempt to close if the popup is still "there"
            if (popupView.Handler != null && popupView.Handler.PlatformView != null)
            {
                try { await popupService.ClosePopupAsync(navigation, token); } catch { }
            }

            throw;
        }
        finally
        {
            mainWindow.ModalPushed -= ModalPushedHandler;
        }

        return finalResult;
    }
}

Mappings and include various return types

public static class PopupViewModelMappings
{
    public static readonly Dictionary<Type, Type> ViewModelToPopup = new()
    {
        { typeof(ProgressPopupViewModel<bool?>), typeof(ProgressPopup) },
        { typeof(ProgressPopupViewModel<int?>), typeof(ProgressPopup) }
    };
}

MauiProgram.cs - how you will register with DI, again depending on our return types

_ = serviceCollection.AddTransientPopup<ProgressPopup, ProgressPopupViewModel<bool?>>();
_ = serviceCollection.AddTransientPopup<ProgressPopup, ProgressPopupViewModel<int?>>();

The PopupViewModel
Note the IPopupConfigurableResultViewModel adapter for consuming the IPopupResult from the V2 service to handle UI dismissals gracefully, set whatever return type you need.

public partial class PopupViewModel(IPopupService popupService) : ObservableObject, IPopupConfigurableResultViewModel<TResult?>
{
    public Func<Task>? FooFunc { get; set; }
    public TaskCompletionSource<TResult?> PopupResultCompletionSource { get; } = new TaskCompletionSource<TResult?>();

PushPopupAsync Usage.. similar to V1 popups

 var result = await popupService.ShowPopupAsync<ProgressPopupViewModel<bool?>, bool?>(App.Current.Windows[0].Navigation, onPresenting: async vm=>
 {
     vm.FooProp = "foo";
     vm.FooFunc= async () =>
     {
        bool success = false;

        // Do whatever on the VM, sets properties etc. and update `success` field as required

        //  The return result value but also signals the popup to close when onPresenting completes
        bool resultSet = progressPopupViewModel.PopupResultCompletionSource.TrySetResult(success);

        if (!resultSet)
        {
               DiagnosticsService.TrackError(
               new InvalidOperationException("PopupResultCompletionSource was already completed"),
               "active_script_list_activation_code_popup_result_already_set");
        }
     };

ModalPushedHandler need only be included if your using Prism like we are.

[belmonmi]

@TheCodeTraveler,
I appreciate your response, and you're absolutely right that there are multiple technical approaches to achieve the same result. However, I think the core issue may not have been clearly communicated.
The challenge isn't finding alternative solutions—it's managing interface contract stability in enterprise environments. When the original IPopupService interface was introduced, it established a specific contract that became part of our architectural foundation across multiple applications. Teams built their patterns, testing suites, and deployment pipelines around this established interface.
While the technical alternatives you've mentioned are valid, they represent fundamental architectural changes rather than simple code updates. In enterprise development, interface evolution requires careful consideration of:

Backward compatibility - Existing consumers shouldn't break
Migration path - Clear upgrade strategies with minimal risk
Testing overhead - Regression testing across dependent systems
Deployment coordination - Synchronized updates across multiple teams/applications

The distinction between "can be done differently" and "should require breaking existing contracts" is crucial for library maintainers. Established patterns like semantic versioning, deprecation cycles, and adapter patterns exist specifically to balance innovation with stability.
The fundamental question is: Should the Community Toolkit prioritize rapid iteration over API stability? For a library that's become infrastructure-level dependency in the .NET MAUI ecosystem, breaking changes without migration paths create significant downstream costs that may not be visible to the library authors.
Would it be possible to consider a dual-approach strategy—maintaining the existing interface while introducing the new patterns? This would allow teams to migrate on their own timeline while still enabling the architectural improvements you're driving toward.
The goal isn't to resist change, but to ensure that critical ecosystem libraries evolve in ways that respect the investment teams have made in building on top of them.
Best regards,
Michael

[belmonmi]

@LeoJHarris,
Good stuff! Thank you for your solution.
Michael.

[LeoJHarris]

@belmonmi 💯

Mark the old API as deprecated, keep it in a few more future releases allowing everyone to migrate slowly whilst keeping up to date across other fixes then completly drop the old API's, even if the new V2 provided some form of param passing that would have helped a ton but feels like all the love is going to shell these days.