I think this whole series perfectly illustrates why application state in React is a nightmare of complexity and performance pitfalls. The fact that you need all this knowledge - that all this code is necessary... Just makes me think React has a serious, fundamental design issue.
I mean, compare this to something like Sinuous, where component state is literally identical to application state: observable("value") and you're done - with precise updates and no concerns about factoring your components for performance.
State management in React is just too much work, which is why people use one of the endless list of state management libraries. The fact that these even exist points to a serious design issue in React.
Unfortunately, I don't think this is something they can or ever will solve - because they have to be backwards compatible, otherwise they lose the whole ecosystem. Not that losing all these state management libraries would be a loss, but they have to stay compatible with component libraries, which likely means they can never fix the fundamental design issues around state management.
Your article series is well written and probably helpful to a lot of people struggling with this complexity in React - but it also perfectly illustrates one of the key reasons why, personally, I'm looking at other options.
As someone coming from Angular, React seems so much more lightweight and simple. Not to mention using JavaScript on Angular is a nightmare. Maybe I'm just clueless, I'm not too much of a web developer tbh. I believe this is why React has become the tool of choice for many companies over Angular.
Yeah that's very true. React is way more flexible than angular js and finding reletively good react devs is easier and faster than finding good angular devs and also learning react is way easier than learning angular but the only thing new people sruggle at is state management, if you see any course or tutorial state management is like one of most dense and long parts of it. So yes react is great but state management in it still needs to be thought more about
Interesting take. I think if you use redux toolkit it's a breeze, it has made managing that state really easy but yeah you're right that state management is a serious issues for whoever is starting to learn react.
I just looked at sinuous and i think you might run into same problem when you share the state between multiple components. Like which component is updating the state when and predicting what state will be after some action. I might be wrong here as I just took a look at it's docs. Could you share some resource on how to manage state accross components?
Also I do know that vue and sevelte also do state management really well you may also wanna look into those.
Redux-zero might be worth a look too... familiar stores, actions, middleware, support for Redux devtools with time-travel, etc. - just no reducers, making it quite a lot simpler. 🙂
I think this whole series perfectly illustrates why application state in React is a nightmare of complexity and performance pitfalls. The fact that you need all this knowledge - that all this code is necessary... Just makes me think React has a serious, fundamental design issue.
I mean, compare this to something like Sinuous, where component state is literally identical to application state:
observable("value")and you're done - with precise updates and no concerns about factoring your components for performance.State management in React is just too much work, which is why people use one of the endless list of state management libraries. The fact that these even exist points to a serious design issue in React.
Unfortunately, I don't think this is something they can or ever will solve - because they have to be backwards compatible, otherwise they lose the whole ecosystem. Not that losing all these state management libraries would be a loss, but they have to stay compatible with component libraries, which likely means they can never fix the fundamental design issues around state management.
Your article series is well written and probably helpful to a lot of people struggling with this complexity in React - but it also perfectly illustrates one of the key reasons why, personally, I'm looking at other options.
As someone coming from Angular, React seems so much more lightweight and simple. Not to mention using JavaScript on Angular is a nightmare. Maybe I'm just clueless, I'm not too much of a web developer tbh. I believe this is why React has become the tool of choice for many companies over Angular.
Yeah that's very true. React is way more flexible than angular js and finding reletively good react devs is easier and faster than finding good angular devs and also learning react is way easier than learning angular but the only thing new people sruggle at is state management, if you see any course or tutorial state management is like one of most dense and long parts of it. So yes react is great but state management in it still needs to be thought more about
Interesting take. I think if you use redux toolkit it's a breeze, it has made managing that state really easy but yeah you're right that state management is a serious issues for whoever is starting to learn react.
I just looked at sinuous and i think you might run into same problem when you share the state between multiple components. Like which component is updating the state when and predicting what state will be after some action. I might be wrong here as I just took a look at it's docs. Could you share some resource on how to manage state accross components?
Also I do know that vue and sevelte also do state management really well you may also wanna look into those.
Redux makes you write a lot of unnecessary code. Changing one action or adding new action leads to change of several files.
Try redux toolkit, it isn't the case anymore
Ok, I'll check it out. Thanks
Redux-zero might be worth a look too... familiar stores, actions, middleware, support for Redux devtools with time-travel, etc. - just no reducers, making it quite a lot simpler. 🙂
Thank you)
It still has mapDispatchToProps and stuff which I find a bit ugly. But yeah, still way better than taditional redux.