I read the whole article, it made a lot of sense to me as we did face the same issues with redux and simiarly mobx. Good job!
For our app, which was made via knockoutJS, have very similar concept to mobx, namely the pub-sub pattern and the computed functions. Just like you said, a lot of complexity comes from asynchronous functions coupled with mobx. So I am wondering what do you think if we structure the app in the way that we will have components handle the service calling, not mobx. This way we take out the step that causes complexity ?
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.
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
I like your point about async stuff bringing a lot of trouble to Mobx.
Moving async stuff to components definitely might work nicely. My only fear would be only that it would again turn into "Redux-esque" architecture, where whenever somebody new comes to the project, you have to explain to them "oh, we don't put async stuff in Mobx stores, we put it in components, blablabla...".
But maybe that's not a huge issue and if everyone in the team is on the same page, I think it would be completely fine to try that approach.
I read the whole article, it made a lot of sense to me as we did face the same issues with redux and simiarly mobx. Good job!
For our app, which was made via knockoutJS, have very similar concept to mobx, namely the pub-sub pattern and the computed functions. Just like you said, a lot of complexity comes from asynchronous functions coupled with mobx. So I am wondering what do you think if we structure the app in the way that we will have components handle the service calling, not mobx. This way we take out the step that causes complexity ?
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.
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
Hey Kevin, thanks for the reply.
I like your point about async stuff bringing a lot of trouble to Mobx.
Moving async stuff to components definitely might work nicely. My only fear would be only that it would again turn into "Redux-esque" architecture, where whenever somebody new comes to the project, you have to explain to them "oh, we don't put async stuff in Mobx stores, we put it in components, blablabla...".
But maybe that's not a huge issue and if everyone in the team is on the same page, I think it would be completely fine to try that approach.
awesome thanks!