Hacker News new | past | comments | ask | show | jobs | submit login

Yea seems like people reach too much for larger "state management" via Redux/Mobx/etc. too quickly without thinking what that means instead of just using State updated via callbacks passed as props. Clearly Redux solves the times where doing that isn't really clear or gets complicated, but often times it sounds from Twitter + Conversations that everything is getting thrown in to Redux for no reason.



I resisted for a long time, but finally switched from a callback model to Mobx and the reason was that ShouldComponentUpdate and ComponentDidUpdate started becoming unbearably hard to manage.

So state management libraries are not solving a unsolvable problem, they are here so that we can write cleaner, more efficient code that potentially can become more performant. At least that's what happened in my case.


Can't you use pure components as long as you make sure that all your callbacks are called with new objects, e.g. using the JavaScript spread notation?

I think the bigger reason that a global state management system becomes necessary is when the shape of your component tree doesn't closely match the shape of your state tree, because that means state (and callbacks) need to be passed down through components that don't care at all about that state simply because one of their distant descendant components does care about it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: