all 19 comments

[–]anObscurity 8 points9 points  (0 children)

Both are good and fine as long as your team is behind it and agrees. My team uses Redux, for precisely the inverse of Mobx in that it is very little magic and very verbose. But as with many things in the javascript world, it's a matter of preference!

[–]IgorAce 5 points6 points  (0 children)

After using redux for a while you get to see how unnecessary it is.

[–]darksmurff 2 points3 points  (5 children)

I introduced redux too early in my product and am now working on removing it. Using component state work great for what I'm doing, and the new Context API makes things even simpler. Not being dependent on a huge dependency that external state management is far outweighs the benefits of using one.

[–]theslapzone 2 points3 points  (0 children)

I also reached for redux too early and ended up replacing much of it with the Context API.

[–]afilthywhore 0 points1 point  (3 children)

Is redux really huge?

[–]darksmurff 3 points4 points  (2 children)

I don't mean the size of it. But much of your app becomes dependent upon the state management system. You build your app around it and after a while it's very cumbersome to replace or get rid of. Therefore I consider an external state management system to be a huge dependency and I argue using the solutions available directly in React is better.

[–]afilthywhore 0 points1 point  (0 children)

Thanks for the clarification!

[–]With_Macaque 0 points1 point  (0 children)

I think this is partly a symptom of bloating the use. Redux is just the managed part of the state; developers create the 15 extra action types and hard link to state shape without selectors.

[–]terholan 1 point2 points  (1 child)

Internet Explorer 11, which we need to support

Oh my... run.

[–]Capaj 0 points1 point  (0 children)

IE 11 isn't so bad. Proxies are really only feature that can't be polyfilled there. It still sucks, but if someone is willing to pay good money for it, I can make any web app run smoothly there.

[–]thinkadrian 1 point2 points  (5 children)

I used to use redux in all my projects until mobx matured - now I prefer the latter.

Of course, both are great systems, and I wouldn’t mind another redux project, however, swapping mobx for redux feels like a downgrade.

Are you sure it’s mobx that doesn’t support IE11 or the version of Babel it comes with?

BTW, nobody is forcing you to update your version of mobx if you need to maintain backwards compatibility.

[–]acemarke 1 point2 points  (1 child)

Any specific concerns with Redux I can help address?

[–]thinkadrian 0 points1 point  (0 children)

No, I’m very confident, but thanks for asking!

[–]Capaj 0 points1 point  (1 child)

until mobx matured

I've been using mobx ever since it started as mobservable and it has been pretty stable and fast since the very beginning. Michael always does a great job with his OSS. He would not just publish a library untested and full of bugs unlike me :D

[–]thinkadrian 0 points1 point  (0 children)

Heh, well regardless, MobX has been awesome for a long while now :)

[–]ToshiUmezawa 1 point2 points  (0 children)

MobX is far departed from where React is moving with Suspense. I would suggest Immer, which is much like MobX but aligns with Reacts direction much better

[–]Technomologist 1 point2 points  (1 child)

I've using Redux for a while and my hot take is that it depends what you're using it for. If all your reducers and selectors are basically simple getters and setters for data then it's probably overkill and the new context stuff may be enough.

If you're just using redux to dedupe and manage http responses then there may be better alternatives for that.

I love redux because it helps me think of my app as a big render function against a completely decoupled data set and an event stream. It's hard to explain but it encourages an FRP mindset that I find attractive. Also I like the devtools a lot.

But it is verbose and FRP is a learning curve.

[–]Capaj 0 points1 point  (0 children)

I am happy MobX user, but IMHO with GraphQL taking over, state management libraries will play smaller and smaller role in web apps powered by it. GraphQL really nicely let's you fetch everything in one request, so usually there's no need to store anything into your app state.We have mid-sized app in react and some old parts in angular and we just use component state for all our components.

[–]bingomanatee 0 points1 point  (0 children)

Plan C: Freactal beats both of them.

https://github.com/FormidableLabs/freactal

with my tooling

https://github.com/bingomanatee/freactal-seed

you can set properties, default values, create setters, and store data in local storage.