-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Blazor: Record Type binding and validation for EditContext/EditForm #31604
Comments
Thanks for your suggestion. Blazor expects it's models to be editable. Adding support for immutable types isn't high on our priority. at this point. We'll reconsider this issue if we get a lot of community feedback. Parking this in the backlog for now. |
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process. |
Just giving a +1 here for this feature, as it would allow using Flux pattern without having to compromise on a mutable state, which is the main principle for code stability. Changing the behaviour is possible with onchange events where we can catch the event and adjust the property by passing a new record, but this is not possible to do so on two-way binding or with oninput events. If not possible to send a modified state, could you - as a backup scenario - make it possible to catch the event and set the new record by user code, without disabling the binding (which, for now, does not work if we change the record). I can provide some test code if needed. |
Thanks for contacting us. We're moving this issue to the |
As part of this issue, we will need to also make sure that this is not Blazor specific and that record types also work fine for model binding in MVC. |
I'd like to add one more use case - sharing DTO types between Blazor and the server REST API. Record types are quite suitable for DTOs and DTOs often (but admittedly not always) can be used as the model for the form. As it stands we need to choose if we want to reuse the DTO for the Blazor form and make it mutable class or duplicate it for the form model and keep it a record in the API |
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process. |
so is not possible to bind Record DTOs to a Blazor GUI form currently? |
not the immutable ones |
I see. |
To be honest I see absolutely no value in mutable records. I use the positional immutable records a lot and never use mutable ones. I suppose you can use them for DTOs if you like them. I personally use classes for the edit dtos while all others are immutable records just because of this issue with Blazor |
Is your feature request related to a problem? Please describe.
Please consider binding and model validation in Blazor with record types. Currently when using the EditForm/EditContext it requires a model with mutable properties for input binding. Having the EditForm/EditContext bind to a record type and emit a new instance with modified state would allow for client-side functionality like state machines, state rewinding and fast-forwarding, mutation batching and other workflows which benefit from immutable state. This functionality and workflow would be similar to the MVC 5 record type binding which allows for form fields binding, field validation and model validation.
https://docs.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-5.0?view=aspnetcore-5.0
Describe the solution you'd like
A simple and idiomatic way to bind to record types similar to the current binding syntax. Understandably the current bind syntax may not be suitable as the field would have to emit a new record instance with the changes, then alert the EditForm/EditContext to update the bound Model property, or let the user handle it emit an event to propagate the changes up (or a combination of both).
The text was updated successfully, but these errors were encountered: