DEV Community

Discussion on: My thoughts on endless battle of React state management libraries (setState/useState vs Redux vs Mobx)

Collapse
 
jbergens profile image
jbergens

I think you may end up with some problem later unless the app is very small. If you put the fetch logic in the component it is hard to share if needed by another component (that is, another component must be able to fetch this data and update the store). If you then move it outside of the component into a helper you are very close to a thunk or action any way but it is outside the components and the store and therefore a bit harder to find. One nice thing with mobx is that almost everything about state and actions can be found in the store.
It could also make writing tests harder. When everything is in a mobx store you can write tests for it. If you split it into a store, some helper and a component you have to test them all combined to know that the application works.

Collapse
 
kevin074 profile image
kevin074

I agree with your observations, namely that if everything's inside the store then you'd have a centralized place for everything. However, I think that's exactly the drawback of the. We had a relatively small app that used redux and had all types of data, global state and service responses, stored in there.

It quickly became a nightmare when there are scaffolding after scaffolding for getting stuffs, which was hard to explain to our team lead who had no hand in building it. It felt as if walking in a labyrinth inside the store. If everything was separated completely, store only has global state, service layer is the controller, cache layer is another, then it would be much clearer.

as for writing tests, you may very well be correct, but I am too newbie at test-writing to comment on :P