Reputation: 23502
I want to ensure I have understood Redux right. My understanding is that it will store the complete state of an application (including all subsystems) like models of all components and cache of fetched data and user generated data. Does that mean I should never use service to load/save state of an component by it's model's id?
I'm making an quiz application, which consist of components like Quiz, Category, Question and Choice. Currently each component calls the web API to fetch data and maintains it's own state itself or with the aid of an service which keeps track of everything by id fields.
I have dedicated service called AnswerService to maintain the state of selected choices, where each Choice component fetches it's state when rendered.
Does migrating to Redux means all of this will be moved to store, and virtually all service will be stateless and dispatch directly to store, and respectively all component models are subscribed from store?
Upvotes: 15
Views: 1263
Reputation: 4172
"Does migrating to Redux means all of this will be moved to store"
No.
If you are using ngrx then the best way to handle this would be with ngrx/effects. This is a companion library that is meant to be "the place to put your async code", or in other words the place to do side effects. So when the component wants some new data it would dispatch a "GET_DATA" action and this would be handled as an ngrx @Effect. Inside of your effect is where you can use your custom service to call out and retrieve the data (so your async services are probably fine and may just need to be tweaked a little). Then you effect returns an action containing the new data back to the reducer which updates the state with the new data. Your component was subscribing to store the whole time so when the state is updated by the reducer the component knows about this change and can automatically update it's own local state.
Upvotes: 3
Reputation: 2216
Thanks for your question. I am facing the same dilemma. The way I did answer myself for now is that I will still have testable services to encapsulate the state changing operations that the "redux" function executes. In my view, that redux function with a huge if statement that you see in basic redux examples is only a beginning... I guess nobody will code like that for real in a big app.... I would say, however, that it looks like a good idea to have this redux intermediary that catches and dispatches any state-changing event to the corresponding service. Not sure still if we want also the read-only gets be encapsulated in the service... maybe not.. but that would be another discussion.
Upvotes: 0