Decide which state management tool to use
GeniaT opened this issue · 20 comments
Hey there,
A state management tool is still to be defined and added to the tech-stack.
Continuing the discussion from Discord, a few options we have: Redux , MobX , use of ContextAPI, ... Please share your view and list any other interesting option that may exist.
I personally didn't work with MobX and use ContextAPI as a substitute to Redux doesn't seem a right choice to me. So it would be Redux for me.
What tool would you go for and why?
While I ❤️ mobx, it would definitely not be good for beginners (decorators, RxJs, etc). Context is nice for small apps but I don't think it would be good for big sites like this. I'm all for Redux, maybe with thunk.
I agree with both of you, Redux with thunk ❤️
I would say the opposite, Mobx is easier to understand. Less boilerplate and less files to navigate through.
Since redux is widely used and there are tons of free resources available online to get familiar with it, It'll be welcoming for both new and existing contributors!
I know there was push back in the chat, but I'm voting React Hooks (useContext with useReducer). :P
If we go Redux, I'd personally prefer Sagas.
I'm on board with whatever the decision is though.
useContext isn't really a mature feature with widespread adoption yet and like @Haxified has mentioned, it isn't particularly well suited for complex apps. I would go with the tried and tested libs like Redux. @timmyichen I am yet to work on a Production app on Next + Redux, though I know it is a widely used combo - would you have experience on this?
We used Next + Redux at Repl.it and it worked fine. They don't really have much intersection so it's really the same as any other React + Redux app. I'm also fine with Redux being used as there are lots of resources available for newcomers to learn from.
Cool that sounds good @timmyichen - I was just wondering about the server-side hydration on first load and re-hydration on client render and if there might be pitfalls that might not be immediately apparent. If it's tried and tested, I'm all for it 👍 👍
We did have some wonkiness around that, but only for the more complex parts of our app - I think since we'll be using it for fairly straightforward purposes we shouldn't run into any hydration issues.
Thanks for all those feedbacks guys, can we consider this as a consensus for Redux?
Redux 100%, have we decided on using thunk/sagas?
Thunk for it's simplicity compared to sagas
Sagas for easy testability, simplicity 💃 and separation of concerns
Redux with Thunk 💯
+1 thunk
what about just ContextAPI and other hooks?
here's one "hooks v redux" article:
@Zeko369 I think this is a succinct explanation of the advantage of sagas from this blog
The benefit to Redux-Saga in comparison to Redux-Thunk is that you can avoid callback hell meaning that you can avoid passing in functions and calling them inside. Additionally, you can more easily test your asynchronous data flow. The call and put methods return JavaScript objects. Thus, you can simply test each value yielded by your saga function with an equality comparison. On the other hand, Redux-Thunk returns promises, which are more difficult to test. Testing thunks often requires complex mocking of the fetch api, axios requests, or other functions. With Redux-Saga, you do not need to mock functions wrapped with effects. This makes tests clean, readable and easier to write.
Another major difference is
Thunks can never act in response to an action. Redux-Saga, on the other hand, subscribes to the store and can trigger a saga to run or continue when a certain action is dispatched.
source
And another advantage that I personally feel is important is that when using the saga method, we have a definite separation of concerns
As for an example, I think this answer on SO from the author compares the two apples-apples and explains the differences very well indeed.
The flip side to using sagas are obviously the new syntax, learning curve. But overall adaptation for sagas is much higher than thunk and repos like the super popular react-boilerplate my @mxstbr (of styled-components) adopted sagas a long long time ago. So it is pretty much the current standard.
Did anyone work with both sagas and thunks in the past ? There doesn't seem to be a favorite yet between the two...
Some stats that may help to decide:
Redux-thunk vs redux-sagas
1,6kk vs 0,6kk weekly downloads
13,4k vs 19,2k stars
2/167 vs 125/1167 opened issues
36 vs 289 contributors
OK - there seems to be an even-ish split between people who prefer Thunk and people who prefer Sagas. They both seem fine to me, so I'm going to say:
Whichever tool is used in the first major contribution to the front end can be the one we stick with. At the end of the day, we just have to choose one and push forward 😄