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