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

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

Open
braidenstiller opened this issue Apr 8, 2021 · 11 comments
Open
Labels
area-blazor Includes: Blazor, Razor Components area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-builtin-components Features related to the built in components we ship or could ship in the future feature-model-binding Priority:2 Work that is important, but not critical for the release
Milestone

Comments

@braidenstiller
Copy link

braidenstiller commented Apr 8, 2021

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

@braidenstiller braidenstiller changed the title Blazor: Consider Record Type binding and validation for EditContext/EditForm Blazor: Record Type binding and validation for EditContext/EditForm Apr 8, 2021
@javiercn javiercn added the area-blazor Includes: Blazor, Razor Components label Apr 8, 2021
@pranavkm
Copy link
Contributor

pranavkm commented Apr 8, 2021

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.

@pranavkm pranavkm added this to the Backlog milestone Apr 8, 2021
@ghost
Copy link

ghost commented Apr 8, 2021

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.

@pranavkm pranavkm added the enhancement This issue represents an ask for new feature or an enhancement to an existing one label Apr 8, 2021
@javiercn javiercn added the feature-blazor-builtin-components Features related to the built in components we ship or could ship in the future label Apr 20, 2021
@jp-gouigoux
Copy link

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.

@mkArtakMSFT mkArtakMSFT modified the milestones: Backlog, .NET 8 Planning Sep 28, 2022
@ghost
Copy link

ghost commented Sep 28, 2022

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
Copy link
Member

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.

@TanayParikh TanayParikh added area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates feature-model-binding webui-P1-TP labels Nov 9, 2022
@mkArtakMSFT mkArtakMSFT added the Priority:2 Work that is important, but not critical for the release label Nov 10, 2022
@Eirenarch
Copy link

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
Copy link

ghost commented Jun 29, 2023

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.

@mkArtakMSFT mkArtakMSFT removed this from the Backlog milestone Nov 5, 2023
@mkArtakMSFT mkArtakMSFT added this to the BlazorPlanning milestone Nov 5, 2023
@mkArtakMSFT mkArtakMSFT modified the milestones: Planning: WebUI, Backlog Nov 17, 2023
@dotnet dotnet deleted a comment Nov 17, 2023
@Trapulo
Copy link

Trapulo commented Jun 11, 2024

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

@Eirenarch
Copy link

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

not the immutable ones

@Trapulo
Copy link

Trapulo commented Jun 11, 2024

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
Copy link

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

@mkArtakMSFT mkArtakMSFT modified the milestones: Backlog, .NET 10 Planning Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-builtin-components Features related to the built in components we ship or could ship in the future feature-model-binding Priority:2 Work that is important, but not critical for the release
Projects
None yet
Development

No branches or pull requests