Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow to pass parameters to dialogs #2470

Open
MarvinKlein1508 opened this issue Jul 30, 2024 · 2 comments
Open

feat: allow to pass parameters to dialogs #2470

MarvinKlein1508 opened this issue Jul 30, 2024 · 2 comments
Labels
community:request Issues specifically reported by a member of the community. status:needs-investigation Needs additional investigation vNext For the next major version

Comments

@MarvinKlein1508
Copy link
Contributor

MarvinKlein1508 commented Jul 30, 2024

🙋 Feature Request

I'm writing this feature request as a result of my discussion, which can be found here: #2443

The issue here is to collect and exchange feedback regarding the DialogService within this library. In my opinion, the current way dialogs work isn't very useful in many cases because their use case only fits in very specific ways.

😯 Current Behavior

Currently, you can only bind to components that implement either IDialogContentComponent or IDialogContentComponent<T>. In addition, you cannot pass additional parameters to the dynamic component. You either need to add them to your model or create custom parameters that inherit from DialogParameters and cast them within your component every time. Both ways result in much boilerplate code, which is hard to maintain.

💁 Possible Solution

I would like to be able to use this kind of syntax:

private Modal _editModal = default;

protected override async Task ShowEditModalAsync(Customer? input = null)
{
// Provide parameters as dictionary
    var parameters = new Dictionary<string, object>
    {
        { nameof(CustomerForm.Model), input ?? new() },
        { nameof(CustomerForm.OnCancel), EventCallback.Factory.Create(this, _editModal.HideAsync) }, // Bind to modal close if you want
        { nameof(CustomerForm.OnSave), EventCallback.Factory.Create<Customer>(this, SaveAsync) } // Bind to other methods which has an input parameter
    };

    string modalTitle = input is null ? "New customer" : "Edit customer";

    await _editModal.ShowAsync<CustomerForm>(modalTitle, parameters: parameters);
}

The component itself should then create an instance of the provided component and fill all parameters. It would be even better if I could pass functions from the dialog itself as parameters.

🔦 Context

I want to pass additional parameters from outside to my dynamic component. For example, some sort of filters or rules for displaying content within the component itself.

In addition, I want to be able to use any component as a dynamic component for a dialog without having to implement the IDialogContentComponent or IDialogContentComponent interfaces every time.

💻 Examples

Let's say I have a component that displays a user list and allows me to filter them by name. So, I provide a filter class named UserFilter, which contains both age and username attributes.

Now, I have certain views. The first view should always display users above the age of 18. The other one can be changed according to the user's needs. So, I don't want the user to change the value for the age filter in view 1.

In Blazor, I would achieve this like this:

View 1:

<UserSearch Filter="MyFilter" AllowToChangeAge="false" />

View 2:

<UserSearch Filter="MyFilter" AllowToChangeAge="true" />

The alternative would be to apply this property to my filter class, but I don't want to change my filter model. In some cases, I cannot change the class at all since I cannot modify the original source files.

@microsoft-github-policy-service microsoft-github-policy-service bot added the triage New issue. Needs to be looked at label Jul 30, 2024
@vnbaaij vnbaaij added community:request Issues specifically reported by a member of the community. status:needs-investigation Needs additional investigation and removed triage New issue. Needs to be looked at labels Jul 30, 2024
@vnbaaij
Copy link
Collaborator

vnbaaij commented Jul 30, 2024

Hi,

Because of vacation period, this will not see much activity in the coming weeks from my side.

@MarvinKlein1508
Copy link
Contributor Author

@vnbaaij don't worry. I just wanted to sort this one out of my large post because this is really important to me. Have a nice vacation! :)

@vnbaaij vnbaaij added the vNext For the next major version label Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community:request Issues specifically reported by a member of the community. status:needs-investigation Needs additional investigation vNext For the next major version
Projects
None yet
Development

No branches or pull requests

2 participants