Redux is about state evolution in time, while context API is about drilling props down, while GraphQL is just about querying data from your backend. That are 3 different ideas, absolutely orthogonal to each other.
It's wrong to use Redux to drill props, or query data from backend (without state evolution, aka handling loading state machine).
It's wrong to rely on ContextAPI for complex state operations.
It's not efficient to use GraphQL as client-side state manager - resolvers are not compact and not optimized for FE in terms of memoization.
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.
Sorry, but I have to answer.
Reduxis about state evolution in time, whilecontext APIis about drilling props down, whileGraphQLis just about querying data from your backend. That are 3 different ideas, absolutely orthogonal to each other.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.