The simplest way to pass data from a parent to a child in a React Application is by passing it on to the child's props. But an issue arises when a ...
For further actions, you may consider blocking this person and/or reporting abuse
You are referring to a style of Redux there that is not the recommended style of writing Redux for over two years now. Modern Redux looks very differently and is about 1/4 of the code. It does not use switch..case reducers, ACTION_TYPES or createStore and is a lot easier to set up than what you are used to.
I'd highly recommend going through the official Redux tutorial and maybe updating this article afterwards.
Thanks for pointing it out, please take a look now
Its great to have one of the creators of Redux reviewing my article!
Now the Redux portion looks okay for me - as for the comparison, I'd still say it doesn't 100% stand as the two examples just do very different things - the Context example only takes
initialValuefrom somewhere and passes it down the tree, but you don't even have code to change that value ever in the future.So if you add code for that (and also pass down an option to change that data), you will probably already here get to a point where the Context is already more code than the Redux solution.
I'm not entirely sure whether I agree on this point. Using context with data update would only take 4 more lines:
useStatein the ParentinitialValueIn the end, it usually ends up as quite some more code - see kentcdodds.com/blog/how-to-use-rea... for example.
But just taking your examples side by side:
That in the end leaves the
configureStorecall - and that are three lines. You will probably save more code by usingcreateSlicevs manually writing a Provider.But I had added the Provider in the Context example 😐
You are talking about using
useReducerhook with the Context API. I am suggesting that if one is required to modify the data, one should definitely opt for Redux. In case only sharing the data with the Child Components is required, Context would be a better solutionYeah, but you are not using the
Parentanywhere, which is kinda equivalent to using theProviderin Redux, kinda making it look like one step less for Context ;)As for the "not using
useReducer" - seems like I read over that - in that case I 100% agree. :)"I am suggesting that if one is required to modify the data, one should definitely opt for Redux." - can you elaborate? What specific advantages Redux has over using reducers with
useReducerin React? Thanks!@gottfried-dev The problem is not
useReducer, which is great for component-local state, but Context, which has no means of subscribing to parts of an object, so as soon as you have any complicated value in your context (which you probably have if you need useReducer), any change to any sub-property will rerender every consumer, if it is interested in the change or not.I myself really don't like using redux toolkit. Feel like I have more control when using the old way
Which part of it exactly is taking control away?
Oh, btw.: if it is only one of those "I need the control only 10% of the time" cases - you can always mix both styles. RTK is just Redux, there is absolutely no magic going on that would prevent a mix of RTK reducers and hand-written reducers.
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.
Redux used to be my first choice for large applications but these days I much prefer to use the Context API. Still good to know Redux though just in case and many projects and companies still require you to know it.
Also, if you need to maintain some sort of complex state for any mid-level project, you can still create your own reducer using React's Context API itself, before reaching out for redux and adding external dependencies to your project initially.
But you might take a performance hit. Redux seems to be better performance-wise when you intend to update the shared data a lot - see stackoverflow.com/a/66972857/7677851.
If used correctly that is.
Hello, I have developed a library, react-context-slices which allows to manage state through Context easily and quickly. It has 0 boilerplate. You can define slices of Context and fetch them with a unique hook,
useSlice, which acts either as auseStateoruseReducerhook, depending on if you defined a reducer or not for the slice of Context you are fetching.One of the best and most overlooked alternatives to Redux is to use React's own built-in Context API.
Context API provides a different approach to tackling the data flow problem between React’s deeply nested components. Context has been around with React for quite a while, but it has changed significantly since its inception. Up to version 16.3, it was a way to handle the state data outside the React component tree. It was an experimental feature not recommended for most use cases.
Initially, the problem with legacy context was that updates to values that were passed down with context could be “blocked” if a component skipped rendering through the
shouldComponentUpdatelifecycle method. Since many components relied onshouldComponentUpdatefor performance optimizations, the legacy context was useless for passing down plain data.The new version of Context API is a dependency injection mechanism that allows passing data through the component tree without having to pass props down manually at every level.
The most important thing here is that, unlike Redux, Context API is not a state management system. Instead, it’s a dependency injection mechanism where you manage a state in a React component. We get a state management system when using it with useContext and useReducer hooks.
A great next step to learning more is to read this article by Andy Fernandez: scalablepath.com/react/context-api...
Can you give me some explanation to what you meant when you wrote Context is DI.
Hi, We have build out site in react: upride.in , which tech stack should be better in 2024 as we want to do a complete revamp for faster loading.
if anyone can help for our site that how we can make progress.
I found Redux to be easier to setup and work with than Context API. I migrated a library I was building in Redux to context API and reused most of the reducer logic, but the amount of optimization and debugging I had to do to make the same functionality work was a nightmare in Context. It made me appreciate Redux more and I switched back to save time. It was a good learning to know the specific use case and limitations of context.
I too am a huge fan of redux for most projects!
Exciting topic! 🚀 I love exploring the nuances of state management in React, and finding the sweet spot between Redux and Context API for optimal performance and simplicity. What factors do you prioritize when making the choice? 🤔
@ IDURAR , we use react context api for all UI parts , and we keep our data layer inside redux .
Here Article about : 🚀 Mastering Advanced Complex React useContext with useReducer ⭐ (Redux like Style) ⭐ : dev.to/idurar/mastering-advanced-c...
Context: Specifically designed for static data, that is not often refreshed or updated.
Redux: Works like a charm with both static and dynamic data.
I've working on a complex project only with context, I didn't see this point. Simply using getters and setters (it's the same thing that use useState) in context do all the work. Integrates very well with hooks and custom hooks and also easy to read.
Can you explain why redux it's better at this point?
If you work on a huge project (where you are new to the codebase) with context, you will be running up & down the Dom to find the origin of the data
I compared the two 3 years ago. At that moment Context API was still new but obviously the winner IMO.
I would like to point that Context API is not a state management solution, but a dependency injection solution. You can do use it to inject whatever you like, including state. For state, there can be some performance implications if because components that use a context re-render that component every time the context value changes, and that's when state management libraries come in, they with fine grained state updates and rendering by selecting which piece of state to listen
I think Redux plays a big role when you need to develop a complex application, that requires to integrate features that have a lot of states or in our case actions. One might argue that we can use useReducer apis inside a context to handle the long and nested states, updating them when particular actions are performed, but then just like reinventing the wheel we are developing something like redux only. What I understand is both are two different ways of using the context and reducer features that React provides, we can choose which one to use.
But when there is the case of fetching data from server, I think the latest RTK (Redux Toolkit) is very far ahead as it gives a solution to integrate apis, and render data into state, which in case of context apis, we have to manually integrate it
I hate redux, It is very complicated
Try Teaful github.com/teafuljs/teaful 😊
There are some great benefits to using Context API. Context API works best for small projects, where large amounts of debugging isn't required. Our developers broke down a few specific use cases where Context API is the better choice.
dev.to/mohitm15/starting-with-reac...
i’m come back .the team for me .i love you.how old are you. it me dont fine.the team help me last time . thank
try to take a look at this
github.com/priolo/jon
Wow, this article really inspires me a lot.
Good post, Tapajyoti!
Presently the Revival segment looks acceptable for me - concerning the examination, I'd in any case say it doesn't 100 percent stand as the two models simply do altogether different things - the Setting model just takes initialValue from some place and passes it down the tree, however you don't have code to change that esteem ever from now on.
So on the off chance that you add code for that (and furthermore pass down a choice to change that information), you will presumably currently here reach a place where the Setting is now more code than the Revival arrangement.
As you can see in your example you have created a provider that provider iteself uses
react.context api