Referring to your example, I can write a blog post, too:
Context API vs. ES6 import
Context API is too complicated. I can simply import MockData from './mockData' and use it in any component. Context API has 10 lines, import only 1 line.
Then you can write another blog post Redux vs. ES6 import.
There are maybe projects which
need to mutate data
want smart component updates
want time-travel for debugging
want a solid plugin concept for global state management
And then there are devs reading blogs about using redux is too complicated and end up introducing their own concepts and ideas around the Context API without knowing one thing about immutable data optimizations and so on.
You can use a react context to solve problems that are also being solved by redux, but some features and optimizations are not that easy for homegrown solutions. I mean try it out - it's a great exercise to understand why you should maybe use redux in your production code or stick to a simpler solution that has less features at all.
I'm not saying, that you should use redux in every project, but redux is not just some stupid boilerplate around the Context API => if you need global state utils check out the libs built for it. There are also others than redux.
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.
Referring to your example, I can write a blog post, too:
Context API vs. ES6 import
Context API is too complicated. I can simply
import MockData from './mockData'and use it in any component. Context API has 10 lines,importonly 1 line.Then you can write another blog post
Redux vs. ES6 import.There are maybe projects which
And then there are devs reading blogs about using redux is too complicated and end up introducing their own concepts and ideas around the Context API without knowing one thing about immutable data optimizations and so on.
You can use a react context to solve problems that are also being solved by redux, but some features and optimizations are not that easy for homegrown solutions. I mean try it out - it's a great exercise to understand why you should maybe use redux in your production code or stick to a simpler solution that has less features at all.
I'm not saying, that you should use redux in every project, but redux is not just some stupid boilerplate around the Context API => if you need global state utils check out the libs built for it. There are also others than redux.