4 ms·
I would propose a fourth option, use two reducers to decouple loading of data with actual data. Both reducers listen to the same events and update independently
by pg_bot 9y ago
I would propose a fourth option, use two reducers to decouple loading of data with actual data. Both reducers listen to the same events and update independently. Your data ends up looking like { picturesLoading: false/true, pictures: [] }, which everyone can understand. Your reducers look like:
const picsLoadingReducer = (state = false, action) => {
switch (action.type) {
case PICS_REQUEST: return true;
case PICS_FAILURE: return false;
case PICS_SUCCESS: return false;
default: return state;
}
};
const picsReducer = (state = [], action) => {
switch (action.type) {
case PICS_FAILURE: return action.payload;
case PICS_SUCCESS: return action.payload;
default: return state;
}
};
IMO this is a bit more simple since we don't mix two concepts (am I loading data, what is the data to be rendered).
- ncphillips 9y agoThis is effectively the same solution as the authors second option.
- pg_bot 9y agoYep! However the reason why I've written this was not to demonstrate my own creativity it was more to show that the concerns that the author had with option 2 disappear when you approach the problem from a different perspective. Your codebase doesn't become more complex as you add more actions since the loading reducer doesn't need to change. You are also less likely to run into bugs since a boolean is a better primitive for the behavior he is describing.
- jjnoakes 9y agoThis doesn't avoid the split brain concern completely though: your suggestion has 4 states, and one of them is invalid (picturesLoading: true, pictures: non-empty). If a refactoring or some other edit of the source leads to that state, the pictures may not get rendered (if the pictures are right but picturesLoading is wrong), or the wrong pictures may get rendered (if picturesLoading is right and pictures is wrong).
- pg_bot 9y agoI'm confused by why you think that there is an "invalid" state in this situation. The canonical example for that state is pagination. I have thousands of pictures loaded on a server but due to resource constraints the server only responds with 25 pictures. When I scroll to a specific point we make a request to load more pictures. Therefore I end up in the state of pictures being non empty and picturesLoading being true. If I were in charge the UI for that application, I might change the opacity of the container to signal that we are loading in new data. When we get a response from the server we can either append the data to the pictures array or we can replace it with the new data. Depending on how you want to build your product, either choice is valid.
- jjnoakes 9y agoThe article talked about representing 3 states, and you suggested encoding those 3 states in a way that has the same split-brain issue that the article discussed. You can tell that 4 states doesn't match up with the article based on how the loading state is rendered - the pictures are ignored in those examples. Now sure, if you decide you really do need 4 states, then that's a different story and your suggestion works just fine. But that's not a solution to the article's problem.