Blazor handling of overlay components

[Kebechet]

Summary

Blazor guidelines discourage users from creating Blazor components from .cs files and at the same time they show warning BL0005: Component parameter should not be set outside of its component. I understand that it is by design.

This behavior is okay for most cases. Until you start to work with overlay components. For example Popups or BottomSheets then it becomes quite PITA to follow this recommendation.

Motivation and goals

Reconsider or change behavior of this warnings/guidelines so that work with similar type of components is much easier.

Current state (3 options how to create popup component)

1. Create the component on the page where do you use it. So in .razor you create element <Popup Arg1="" arg2="" /> and you either reference it by @ref or trigger it's functionality by some special service
2. Create the component from the function in .razor @code{} section. Because only in .razor we can use @<div></div> as the input parameter
3. Create a service with hardcoded parameters. After calling this service it will fill the component somewhere

Disadvantages of these current approaches:

• code placement inconsitancy - we split all UI items into .razor, we dont use @code and all functionality of the UI we extract to .razor.cs. But in .razor.cs we cant use the @<div></div>
• control flow - we would have to place some code responsible for filling the component arguments to @code part. And then call it from .razor.cs
• usually we put a little bit of C# code to blazor elements and not the other way around. So using special syntax like @<div></div> as the method parameter is really ugly

it will be better showcased in EXAMPLES section

In scope / Out of scope

• I really dont know how this should be handled properly

Risks / unknowns

dunno

Examples

Current state in existing component libraries:

Radzen

• @<div></div> as parameter in .razor @code section

@code {
    async Task ShowDialogWithCustomCssClasses()
    {
        await DialogService.OpenAsync("Dialog with custom CSS classes", ds =>
        @<div>
            This dialog has custom CSS classes.
        </div>, new DialogOptions() {
                    CssClass = "custom-dialog-class",
                    WrapperCssClass = "custom-dialog-wrapper-class"
                });
    }
}

• hardcoded arguments - required to create some SideDialogOptions for each type of dialog component

await DialogService.OpenSideAsync<DialogSideContent>(
    "Side Panel", 
    options: new SideDialogOptions {     
        CloseDialogOnOverlayClick = closeDialogOnOverlayClick, 
        Position = position, 
        ShowMask = showMask 
    });
}

MudBlazor

• creating component in the .razor and then calling it's methods from service

<MudDialog>
    <DialogContent>
        Dialog Content
    </DialogContent>
    <DialogActions>
        <MudButton OnClick="Cancel">Cancel</MudButton>
        <MudButton Color="Color.Primary" OnClick="Submit">Ok</MudButton>
    </DialogActions>
</MudDialog>
@code {
    [CascadingParameter] MudDialogInstance MudDialog { get; set; }

    void Submit() => MudDialog.Close(DialogResult.Ok(true));
    void Cancel() => MudDialog.Cancel();
}

Our approach:

• wherever we inject popup service we can create the component
• for this to work we use reflection to create RenderFragment from already created component provided as input argument.
• in our case the Input (QuestionPopupComponent) is a template component. So if we want to show different popup, we create another template that implements IPopupReturnable<TOutput> or in case of BottomSheets IBottomSheetReturnable<TOutput>
• input arguments are always hardcoded. Inside the popup components we inject In-memory state container service that persists data locally.

//this way of creating the popup is really nice for usage
var isSuccess =  await _popupService.Show(
    new QuestionPopupComponent{
        Title = "Are you sure?",
        Message = "Do you want to continue?",
        ConfirmButtonText = "Yes",
        CancelButtonText = "No"
    }
);

if (isSuccess is null)
{
    // user closed the popup
} 
else if(isSuccess == true)
{
    // user clicked the button that returns true
} 
else if(isSuccess == false){
    // user clicked the button that returns false
}

Discussion

a) Are any of my claims/assumptions incorrect ?
b) What do you think about this way of creating popups, bottom-sheets and other components that overlay the original UI layer ?
c) Is it possible to do this even without reflection ? If RenderFragment builder OpenComponent could accept IComponent or ComponentBase as an argument I could get rid of whole reflection logic.
d) Are there any other ways how such components can be created except those examples I provided ?

[SteveSandersonMS]

Thanks for the explanation. I should start by mentioning that the warning, Component parameter should not be set outside of its component is a good thing in this case, and even if we removed it, it wouldn't make what you're trying to do any simpler. If we didn't have the warning it would seem to imply you can actually create working component instances arbitrarily outside the renderer, and that's not true.

The underlying constraint here is that real components can only be instantiated by the renderer, not by your other code. That's because it's the only way the whole component lifecycle could work. If the renderer doesn't instantiate the component, it couldn't know when to initialize or dispose the component, or whether the same instance was already associated with another part of the render tree, or whether it can populate the DI parameters, or make work any number of other possible future features that involve defining some kind of lifecycle for the component. Things like @rendermode would make no sense either. If you dig into how React or Flutter work, they both also have exactly the same process by which their renderer constructs the actual component instances, and application code only creates descriptors of those components.

As such, the right way to create a component is by calling the RenderTreeBuilder methods to describe the component you want. As you've seen, Razor syntax automates this and makes it feel natural.

So what you're doing with reflection will work, since you're discarding the fake component instances and replacing them with a series of calls to RenderTreeBuilder methods. I agree it's not very nice to have to write that code, and there's no guarantee it will work with all Blazor features, since we may make Razor syntax smarter and able to do things that your existing code doesn't.

To avoid the reflection, which would be better, I can suggest two main options:

1. If you're in a context where it's possible to call into code defined in a .razor file, do that. For example if you're in a .razor.cs file, then you can call from there into methods defined in the @code block of the .razor file. In there, you can use Razor syntax to return a RenderFragment. This is basically the Radzen approach you've illustrated above.
2. Otherwise, stop trying to use component instances as descriptors of components, and instead have actual types for the descriptors. For example, you would have code like:

var isSuccess =  await _popupService.Show(
    new QuestionPopup {
        Title = "Are you sure?",
        Message = "Do you want to continue?",
        ConfirmButtonText = "Yes",
        CancelButtonText = "No"
    }
);

... where QuestionPopup is not a component instance, but is rather just some arbitrary C# class (not derived from ComponentBase or implementing IComponent). Then the logic inside _popupService would accept this QuestionPopup descriptor and use that to render a component based on hardcoded logic about what different QuestionPopup subclasses or parameters mean.

If you really need the caller to be able to specify a completely arbitrary, unknown component type and parameters, the only non-reflection options I can suggest are to really use Razor syntax as described in option 1 above, or to have them pass in the Type instance and a Dictionary<string, object> of parameters and then use DynamicComponent to render the specified component.

If you prefer to retain your current approach of having the caller pass a fake component instance that's fine, but it may be confusing or misleading to them. For example they might try to call methods on it later, or read back the values of bound properties later, and it won't work because the real component instance is actually a whole other object that they can't access.