search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.59k stars 10.06k forks source link

Blazor: Record Type binding and validation for EditContext/EditForm #31604

Open braidenstiller opened 3 years ago

braidenstiller commented 3 years ago

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).

pranavkm commented 3 years ago

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.

ghost commented 3 years ago

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.

jp-gouigoux commented 3 years ago

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.

ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

mkArtakMSFT commented 2 years ago

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.

Eirenarch commented 1 year ago

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

ghost commented 1 year ago

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.

Trapulo commented 5 months ago

so is not possible to bind Record DTOs to a Blazor GUI form currently?

Eirenarch commented 5 months ago

so is not possible to bind Record DTOs to a Blazor GUI form currently?

not the immutable ones

Trapulo commented 5 months ago

I see. I use Records as DTOs. Does make sense to use mutable Records as DTO to bind to GUI, or is it better to go back to Objects?

Eirenarch commented 5 months ago

I see. I use Records as DTOs. Does make sense to use mutable Records as DTO to bind to GUI, or is it better to go back to Objects?

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