Hi everyone,
I am interested to know if in your react workflow would you use Redux or another state management in 2020?
If you are using somethin...
For further actions, you may consider blocking this person and/or reporting abuse
Hi @wolfiton
Last year, I worked on a side project. It was a React app that integrated the Google Places API. In one point I needed global state and using Redux was no.
Also, React Context didn't work because I needed a JavaScript object in another page. My use case was very simple and adding Redux was overcomplicating the app.
What did I found? duix. This is a package that helps managing state in the very precise way without all the boilerplate Redux adds 😅
It was easy to use (for me) and in the end helped me with the specific case I was facing. It is no longer maintained but it shows that a simpler state management is possible. 👍🏽
Thanks for sharing @franciscoquintero, your experience and the detailed reasons why you chose duix.
I really appreciate it.
Saw the update to the post. Go ahead with state machines. Try as much as you can to understand them and see how they could benefit the UIs you build.
In the project I worked we have three different apps.
This guy couldn't be happier, calmer, and doing stuff faster with the MobX, TypeScript, XState stack. He called stuff with Redux "Mental Gymnastics" xD
Thanks for the quick follow up @franciscoquintero,
I will probably try a simple app with Xstate first to see how the data flows and see what states I will have to take into account, besides
"idle".Update: Did your friend tested his code after using Xstate with Jest, is it even possible?
Yes. He tested his code. In his opinion, it was easier because state machines are more predictable.
He used React Testing Library and Cypress. I think one of those tools made the testing part easier for him. I will ask him :)
I've been using mobx lately because I always had a good experience with observables. My goal is to always use technologies that don't impose an unnecessary cognitive strain when writing code.
The reason why I use React is because - unlike other frameworks - it feels very natural to use. Redux doesn't so I try to avoid it.
Thanks for sharing @michalgacka, the reasons why you use Mobx.
Are you using it with typescript or es7?(because you mentioned observables that are Rxjs and for me that sends my thoughts, towards Angular 9 Rxjs).
TypeScript.
It's actually an interesting case as well because I was trying to avoid TypeScript initially similarity to redux. Following the same reasoning, I found that beyond the initial resistance to introduce more complexity, TypeScript reduced the cognitive strain after a few days, while with Redux I never got to a point when I would find it intuitive enough.
I checked the easy-peasy library btw. and I think I'll give it a try on the next project. Looks really good.
I think i will also go with easy peasy or rematch because my stack is scalable by default and Xstate is not.
So I don't want to lose my advantage of scaling by using a nonscalable technology, even though it looks awesome.
Depending on what's your relationship with OOP, I really recommend trying mobx with classes you construct yourself side by side with the functional approaches to really boil the problem down to how you'd solve it if we weren't thrown into this opinionated world :)
I wonder also if mobx felt so natural to me because I only use it for data management (loading, errors, computed, etc.) and transformations and handle the rest using context and local state.
Thank you for sharing your experience @pedrohenriquewindischand, with Redux and also for explaining why you wouldn't use the Context API.
I was wondering if you would try rematch in the future because it promises to use less boilerplate than Redux but to be very configurable.
Also how do you test your react apps?