3 ms·

It's 100% Redux ecosystem responsibility to perform the actions you want. I understand where you come from, as you perfectly described a procedure and it sounds

It's 100% Redux ecosystem responsibility to perform the actions you want. I understand where you come from, as you perfectly described a procedure and it sounds natural to think that way. Redux and Event sourcing systems force you to decompose in 3 functions this procedure - Action creator: the action creator newTodo() creates an action = {type: 'new', body = 'yo', date: new Date()}. This action creator can be colocated in the reducer file. - Selectors: the summary is a denormalized view of the normalized state. Many would argue it is not a business logic but a display logic. Same for the sorting. A selector is a function that takes a part of the state as an input and return a new datastructure. Use reselect if you have perf concerns and want to persist it. It can be colocated code wise with the reducer file. - Saga: for the side effects of sending an email, we use Redux Saga for ol' REST based endpoints. Those can be colocated code wise with the reducer file. So yes you have 4 functions for your todo business logic: some action creators, some selectors, some sagas and the reducer. They can all be in the same file. It takes a bit of practice to figure out what is the right cut-off point. But all in all, interns and old farts like me all grasped it way more easily than Angular 1 scope concept for a more rewarding value.

WA 10y ago
This is helpful, thank you. One note: > Selectors: the summary is a denormalized view of the normalized state. Many would argue it is not a business logic but a display logic. Same for the sorting. Yes, I read about that before. Don't put in the store what can be computed. But in my case, this isn't used in a view, but in a separate "object" that can be shared with others without sharing the underlying data. So, while the report attributes are all computed, they must be stored somewhere for later individual retrieval. Anyways, could you please clarify this: > So yes you have 4 functions for your todo business logic Where do I bundle these 4 functions so that they're called always in the same order? > It takes a bit of practice to figure out what is the right cut-off point. Yes, that's my struggle right now ;)

WA 10y ago

This is helpful, thank you. One note: > Selectors: the summary is a denormalized view of the normalized state. Many would argue it is not a business logic but a display logic. Same for the sorting. Yes, I read about that before. Don't put in the store what can be computed. But in my case, this isn't used in a view, but in a separate "object" that can be shared with others without sharing the underlying data. So, while the report attributes are all computed, they must be stored somewhere for later individual retrieval. Anyways, could you please clarify this: > So yes you have 4 functions for your todo business logic Where do I bundle these 4 functions so that they're called always in the same order? > It takes a bit of practice to figure out what is the right cut-off point. Yes, that's my struggle right now ;)