My approach is to allow the user to edit the DTO that is sent to the API.
When the form is submitted, I Dispatch an action containing that DTO.
A Reducer sets IsSaving = true
An effect calls the server
If the server indicates success then I dispatch a different action with the DTO in it
Any state that has an interest in that piece of data (e.g. Client) has a reducer that reduces the values of the DTO properties into their own immutable states.
First @mr_eking thanks for this excellent series. I've passed it along to several colleagues and it was instrumental in my decision to move forward with Fluxor for our current project.
Second @mrpmorris thank you for Fluxor and also taking the time to make this comment about using DTO's and forms. It was very helpful to me.
Yes, I'm doing exactly the same thing, with the one exception that I'm also storing the form's DTO (which I'm calling "model" above) into the form component's state.
I feel that's ok, since there's no chance for the state of that form's DTO to have any effect on anything else in the application's state. Not other features' states, not even its own feature's state. It merely allows the form's field values a place to live.
If there were something other than the data-bound form itself that has interest in the DTO properties then they would have to get that value via a reducer like everything else.
Firstly, thank you for sharing your blog posts on Fluxor and Blazor. They are very well written and helpful.
I understand your point about whether it is acceptable to "bend the rules" with regard to the immutability of the Fluxor state for this specific use case (UserFeedback). However, I believe a more generically applicable approach would be to change the code in Feedback.razor as follows:
@code {
private UserFeedbackModel model { get; set; } = new UserFeedbackModel();
private void HandleValidSubmit()
{
Dispatcher.Dispatch(new UserFeedbackSubmitAction(model));
}
}
Treating the UserFeedbackModel as a DTO allows the use of standard Razor form features without violating the immutability principle.
Actually, if your underlying model for the edit form needs to respond to Fluxor state changes, I suggest implementing the action subscription pattern instead. In this case, I don't believe that is required at all.
As mentioned by @mrpmorris there is an important difference between the immutable application state being served up by the Fluxor framework and the mutable and not yet dispatched state of the edit form.
My approach is to allow the user to edit the DTO that is sent to the API.
When the form is submitted, I Dispatch an action containing that DTO.
A Reducer sets IsSaving = true
An effect calls the server
If the server indicates success then I dispatch a different action with the DTO in it
Any state that has an interest in that piece of data (e.g. Client) has a reducer that reduces the values of the DTO properties into their own immutable states.
You should avoid having mutable state.
Two thank you's!
First @mr_eking thanks for this excellent series. I've passed it along to several colleagues and it was instrumental in my decision to move forward with Fluxor for our current project.
Second @mrpmorris thank you for Fluxor and also taking the time to make this comment about using DTO's and forms. It was very helpful to me.
Yes, I'm doing exactly the same thing, with the one exception that I'm also storing the form's DTO (which I'm calling "model" above) into the form component's state.
I feel that's ok, since there's no chance for the state of that form's DTO to have any effect on anything else in the application's state. Not other features' states, not even its own feature's state. It merely allows the form's field values a place to live.
If there were something other than the data-bound form itself that has interest in the DTO properties then they would have to get that value via a reducer like everything else.
Hi @mr_eking
Firstly, thank you for sharing your blog posts on Fluxor and Blazor. They are very well written and helpful.
I understand your point about whether it is acceptable to "bend the rules" with regard to the immutability of the Fluxor state for this specific use case (UserFeedback). However, I believe a more generically applicable approach would be to change the code in
Feedback.razoras follows:Treating the UserFeedbackModel as a DTO allows the use of standard Razor form features without violating the immutability principle.
Actually, if your underlying model for the edit form needs to respond to Fluxor state changes, I suggest implementing the action subscription pattern instead. In this case, I don't believe that is required at all.
As mentioned by @mrpmorris there is an important difference between the immutable application state being served up by the Fluxor framework and the mutable and not yet dispatched state of the edit form.
I see @mr_eking 's point here but I'm interested in the thoughts of @mrpmorris ,
Just getting into this pattern and wanted to get your idea straight for the immutable state of things:
Are you transforming the DTO into a record or will it be cloned in the reducer? or just passing that DTO instance in?
And when the server indicates a success, will that DTO be the same instance? or cloned or reconstructed or ...?
For the both of you: library + excellent blog + comments !