This is all accurate, but the differences matter not to a beginner -- and in practice, few use the major benefits of Redux (rewind, fast-forward, state hydration) while they do use it to pass props. Meanwhile memoization sounds great, until you realize you fetch the data only once, or only once in a long while.
So you can say the philosophical drive and even the main advantage of each is totally different, but in many projects (including large ones) these are subservient to the actual business requirements. If this were not true, there would not be unlimited number of Medium articles or people proclaiming so. Simply put it matters not what the libraries were designed for, only what they are used for. You may say that Context API shouldn't be used for complex state operations and you would be right, but neither should Redux be used for complex state operations. That belongs in the memoization layer, for example reselect. Or perhaps even encapsulated in the component itself.
But none of that matters. The main point is, you do not need Redux to do React. Redux is not React, and the documentation of Redux even includes a section for when not to use Redux. Redux is a major stumbling point for many people entering the React ecosystem, but it can be completely avoided until such time the problems it is designed to solve are actually encountered.
In short, no need for Redux to start, and perhaps no need ever.
I could definitely agree - redux is overused and usually not needed. You have to have some complex situations or conditions, which could be easily resolved in “redux way”, not the “component way”, and you may be lucky not to face such situations ever.
But it worth to understand, as long redux and react are based on the same immutable data structures ideology, and they helps to understand each other.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is all accurate, but the differences matter not to a beginner -- and in practice, few use the major benefits of Redux (rewind, fast-forward, state hydration) while they do use it to pass props. Meanwhile memoization sounds great, until you realize you fetch the data only once, or only once in a long while.
So you can say the philosophical drive and even the main advantage of each is totally different, but in many projects (including large ones) these are subservient to the actual business requirements. If this were not true, there would not be unlimited number of Medium articles or people proclaiming so. Simply put it matters not what the libraries were designed for, only what they are used for. You may say that Context API shouldn't be used for complex state operations and you would be right, but neither should Redux be used for complex state operations. That belongs in the memoization layer, for example reselect. Or perhaps even encapsulated in the component itself.
But none of that matters. The main point is, you do not need Redux to do React. Redux is not React, and the documentation of Redux even includes a section for when not to use Redux. Redux is a major stumbling point for many people entering the React ecosystem, but it can be completely avoided until such time the problems it is designed to solve are actually encountered.
In short, no need for Redux to start, and perhaps no need ever.
I could definitely agree - redux is overused and usually not needed. You have to have some complex situations or conditions, which could be easily resolved in “redux way”, not the “component way”, and you may be lucky not to face such situations ever.
But it worth to understand, as long redux and react are based on the same immutable data structures ideology, and they helps to understand each other.