The only reason it's re rendering is because you put the state on the App component, that's what's re-rendering. This is not a Context problem, it is a logic problem, if you create a separate file with the context of the app and pass it to its children you wont get re-renders.
The children of the context provider, their children, grandchildren and great grandchildren will all get re-rendered. That’s the issue and it is a context problem.
Yes, you will get re-renders. Components cannot selectively consume individual pieces of a context, the most obvious solution to this is splitting up context into a bunch of different contexts.
I thought that's how context is normally supposed to work? I don't think Context actually causes rerenders but since you're declaring the state and passing that into Context anytime the state changes it will cause the whole context wrapper to re-render?
This is a known issue in React core. If you look into other store libraries (e.g Redux, Zustand, Jotai...) they only subscribe and re-render the target components. Not all children!
@@CoderOneif you create a context provider and manage it state in deferent file instead in the App component it will fix the Cart component re-render and also you can create separated contexts one for cart and second for products you can avoid CartList component rerender when cart state change or use zustand instead
Only issue I have with this video is you're saying "re-render" often, but that's not actually what's happening. A functional component's function being invoked doesn't mean the DOM was updated. If a function call results in the DOM being updated that's a re-render. This is just React calling the function to see if the DOM needs to be updated, which it doesn't, so the expensive part of redrawing the DOM gets skipped. That said, it's still extra work that's being done pointlessly. And depending on what you have going on in your components it could be a major performance hit. So it's worth keeping this in mind, and I'll take note of this context issue from now on! Thanks!
I think the term got overloaded in the context of React, what you are talking about is somewhat confusingly called a re-paint while re-render is used to mean render function call in react.
do you have any resource that deep-dives the last bit around putting console.log inside the useEffect vs directly in the function body - you mentioned something about concurrent rendering - does it mean that React concurrent rendering would re-execute your function but it may not actually re-render (because useEffect is not called)? but why?
Honestly, i think I'll just stick with using context the way it is, React is fast, no cap.... I'll only resolve to this if i have noticable performance issues, and not when my component is rendering just a little more than normal
bad explanation about why cart is being re-rendered in the "bad" way example you have the state in App component, if you change state there it will re-render all the components, including cart, and cart will log being re-rendered, also you're using useEffect without a dependency "[]", why not just console.log in function body directly?, you don't need useMemo here what you can do is create a usable function that has the state in it, so the state isnt App level, but rather another component level that returns the providers and children that it will enwrap if you re-render App by changing one of the states, it will re-render any component in the whole app anyway if it's not in cached with useMemo lol I am gonna explain again just to make sure if you have an App and you return the simples component you can imagine u use useState in App and change the state of that variable, the simplest component will re-render, that's what you're basically doing what I am saying to do is, to create a component that will take in children through props, you use useState inside for state management and return provider writing the children changing that state wont re-render the cart if you want to know more about that why that is, google "blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior #component-render-optimization-techniques" and search for "component-render-optimization-techniques"
Of course you will rerender the hole app, because you have two states defined in the App component, every time some of its children call setState on these products or cart, the hole app will rerender. Instead of putting all children components inside .Provider, you should only put {children} as prop in it. And this way, you will not trigger a rerenders. And second, every component that is subscribed to this context, will rerender, regardless of not using cart, but using products. This is your fault that you mixed two different contexts into one. You should create two different contexts one for the cart and another for the products, then everything will work fine without unnecessary rerenders. If you want to mix all of your logic into one place, one src of truth then State management library like Redux, because the contextAPI is not created for mixed logic
I decided to try context a couple months ago for the first time on a work project and im not sure i really understood it but shoe horned it in anyway and got everything working or so i thought, now nearing the end of a project and getting all these unintended re-renders from parent state changes Q_Q no idea how to fix it..
I saw someone using context with refs and a pup sub system. that may be the new approach for me. Using refs stopped the propagation of changes while subscribing to specific stores allowed for only the specific component to update its own state with the new info and make the change there.
In my opinion it's too much pay to deal with refs and pub sub for a simple context. I would switch to Zustand or Redux. at least for the newer features!
@@CoderOne yea I keep hearing about both again. Redux definitely upped their game. But I try to limit imports. Is it an issue of performance or just ease of setting up as to why I should switch?
@@user-tk5wt2xu9s not really. I just learned and used it in 3 days. It just took that much time to learn react-redux and redux toolkit. Trust me they are very good. You can maintain state in small slices. Not everything in one place. Also state updates does not trigger all app like context does .
Context is not a global state manager. React describe it as another (smartest) way to pass props to children. So it's normal that every child will refresh changing params to the context. Thats why redux exists.
useContext is just another useless React hook. I personally just use Jotai, matter of fact, most of the time I just write Jotai myself. If you've never done that yourself, you might think it's complex but it's only around 10 lines of code that you only write once throughout your app.
@@najlepszyinformatyk1661 really nice answer, I thought to examinate the library and to see how they "deal" with it. You can watch the video which I posted in the comments bellow, use-selector-context is using the original context too and I think it is hard to say is it with better performance or not.
Not gonna work. React.memo() only works if props/hooks don't change. React useContext literally passes down the parent's props to *all* children under it. So any of those props changes, both parent and all children re-render
🎉Our Newsletter is live! Join thousands of other developers
islemmaboud.com/join-newsletter
Personally, I think Zustand is a perfect client-side state management library
Zustand literally nailed client state management. End of conversation
@@junsgk Agree. Zustand with well-defined slices is the best
We're using for all projects at our company but this library also looks fine. It simply comes down to a personal preference.
Reatom
True. No headaches. Just straight to the point.
The only reason it's re rendering is because you put the state on the App component, that's what's re-rendering. This is not a Context problem, it is a logic problem, if you create a separate file with the context of the app and pass it to its children you wont get re-renders.
Yes, this is the solution we dont need to use any external library for this
Yes, fully agree! I thought about this during all the video.
The children of the context provider, their children, grandchildren and great grandchildren will all get re-rendered. That’s the issue and it is a context problem.
Yes, you will get re-renders. Components cannot selectively consume individual pieces of a context, the most obvious solution to this is splitting up context into a bunch of different contexts.
If you also put a different file . It will rerender all the context consumer
I thought that's how context is normally supposed to work? I don't think Context actually causes rerenders but since you're declaring the state and passing that into Context anytime the state changes it will cause the whole context wrapper to re-render?
Exactly
This is a known issue in React core. If you look into other store libraries (e.g Redux, Zustand, Jotai...) they only subscribe and re-render the target components. Not all children!
@@CoderOneif you create a context provider and manage it state in deferent file instead in the App component it will fix the Cart component re-render and also you can create separated contexts one for cart and second for products you can avoid CartList component rerender when cart state change or use zustand instead
@@CoderOne thanks that's good to know. :)
@@YacineAhmaichbut notice that all the context consumers will rerender .hence ,therefore provider should not have more state
redux-toolkit uses a Provider as well, I remember this won't have a rerender on the entire sub components, corret me if I'm wrong please.
What the plugin prints before functions "Ask Easy code Explain ... "?
Only issue I have with this video is you're saying "re-render" often, but that's not actually what's happening. A functional component's function being invoked doesn't mean the DOM was updated. If a function call results in the DOM being updated that's a re-render. This is just React calling the function to see if the DOM needs to be updated, which it doesn't, so the expensive part of redrawing the DOM gets skipped.
That said, it's still extra work that's being done pointlessly. And depending on what you have going on in your components it could be a major performance hit. So it's worth keeping this in mind, and I'll take note of this context issue from now on! Thanks!
I think the term got overloaded in the context of React, what you are talking about is somewhat confusingly called a re-paint while re-render is used to mean render function call in react.
do you have any resource that deep-dives the last bit around putting console.log inside the useEffect vs directly in the function body - you mentioned something about concurrent rendering - does it mean that React concurrent rendering would re-execute your function but it may not actually re-render (because useEffect is not called)? but why?
Honestly, i think I'll just stick with using context the way it is, React is fast, no cap.... I'll only resolve to this if i have noticable performance issues, and not when my component is rendering just a little more than normal
Most optimisation is premature. Wait until you need it.
Exactly 🙏
bad explanation about why cart is being re-rendered in the "bad" way example
you have the state in App component, if you change state there it will re-render all the components, including cart, and cart will log being re-rendered, also you're using useEffect without a dependency "[]", why not just console.log in function body directly?, you don't need useMemo here
what you can do is create a usable function that has the state in it, so the state isnt App level, but rather another component level that returns the providers and children that it will enwrap
if you re-render App by changing one of the states, it will re-render any component in the whole app anyway if it's not in cached with useMemo lol
I am gonna explain again just to make sure
if you have an App and you return the simples component you can imagine
u use useState in App and change the state of that variable, the simplest component will re-render, that's what you're basically doing
what I am saying to do is, to create a component that will take in children through props, you use useState inside for state management and return provider writing the children
changing that state wont re-render the cart
if you want to know more about that why that is, google "blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior #component-render-optimization-techniques" and search for "component-render-optimization-techniques"
Why you put log with render inside useffect? It should log info being standalone console log anywhere in the body of component
If you stick a bit longer till this part 11:53 you would understand why!
Can you provide sandbox to try myself?
Of course you will rerender the hole app, because you have two states defined in the App component, every time some of its children call setState on these products or cart, the hole app will rerender. Instead of putting all children components inside .Provider, you should only put {children} as prop in it. And this way, you will not trigger a rerenders. And second, every component that is subscribed to this context, will rerender, regardless of not using cart, but using products. This is your fault that you mixed two different contexts into one. You should create two different contexts one for the cart and another for the products, then everything will work fine without unnecessary rerenders. If you want to mix all of your logic into one place, one src of truth then State management library like Redux, because the contextAPI is not created for mixed logic
I decided to try context a couple months ago for the first time on a work project and im not sure i really understood it but shoe horned it in anyway and got everything working or so i thought, now nearing the end of a project and getting all these unintended re-renders from parent state changes Q_Q no idea how to fix it..
I already used it with RTK query. Make selectors. Same approach
How does this relate to: "This Context API Mistake Ruins Your Whole React App (All Components Re-Render)" by ByteGrad? Doesn't that solve the issue?
I love ByteGrad
Why don't use simply customHook asking for the data object of the context
Which vs code theme u are using @coderone please reply
Halcyon
I saw someone using context with refs and a pup sub system. that may be the new approach for me. Using refs stopped the propagation of changes while subscribing to specific stores allowed for only the specific component to update its own state with the new info and make the change there.
In my opinion it's too much pay to deal with refs and pub sub for a simple context. I would switch to Zustand or Redux. at least for the newer features!
@@CoderOne yea I keep hearing about both again. Redux definitely upped their game. But I try to limit imports. Is it an issue of performance or just ease of setting up as to why I should switch?
it reminds me in VueJS simply provide("key", "value") and inject("key"), it's blazingly fast 🙄
Vue is underrated imo
its okay, but i prefer zustand, jotai or rtk
can I have the github repo?
Web frontend articles are filled with "use this instead"
Redux ?
too complicated. so many abstractions
@@user-tk5wt2xu9s not really. I just learned and used it in 3 days. It just took that much time to learn react-redux and redux toolkit. Trust me they are very good. You can maintain state in small slices. Not everything in one place. Also state updates does not trigger all app like context does .
I'm with team Zustand 😅
@@laxmiprasanna4092 exactly, I feel like many people haven't actually tried redux toolkit.
Context is not a global state manager. React describe it as another (smartest) way to pass props to children. So it's normal that every child will refresh changing params to the context.
Thats why redux exists.
thanks for this video
dont use react
zustand!
👍🙏
You Just avoid that using the pattern provider and stop using useContext like a junior dev
I stopped watching after 2 minutes because I struggle to understand you. It would help if you were to articulate better or speak slower
Use this instead, use this instead.. nonsense
useContext is just another useless React hook.
I personally just use Jotai, matter of fact, most of the time I just write Jotai myself. If you've never done that yourself, you might think it's complex but it's only around 10 lines of code that you only write once throughout your app.
@@icheckedavailability Did you try google?
I believe both are made by the same dude, and i think he actually just recently released a 3rd state management library too
do you know that Jotai uses context as well? :) github.com/pmndrs/jotai/blob/main/src/react/Provider.ts
I will take a look. Usually useContext for small states is not a problem.
@@najlepszyinformatyk1661 really nice answer, I thought to examinate the library and to see how they "deal" with it. You can watch the video which I posted in the comments bellow, use-selector-context is using the original context too and I think it is hard to say is it with better performance or not.
So, Its better to go with redux. Subscribed btw.
jotai is much better choice
wrap the component with memo() ?
Not gonna work. React.memo() only works if props/hooks don't change. React useContext literally passes down the parent's props to *all* children under it. So any of those props changes, both parent and all children re-render