Other than your use of `function reducer() {}` instead of doing `const reducer = () => {}` , this was actually a reaaaaaly good intro to the store, context, dispatch, and reducers. You're using separate components and files, and you have a real useful example. Thank you very much for this, it's helped me tremendously!
〈evie.codes〉 thank you! I’m curious why you say using an arrow function is better when there wasn’t a need for auto binding. Anon Arrow functions generally cause a bit more overhead since they are recreated every time they are called instead of referenced every time like how a standard function works. Sometimes I find them useful and convenient but if I don’t need the convenience, then I don’t see why not use a standard function.
@@WebDevProfesh Well, all your components at this point are functional components, right? So they're arrow functions, which aren't any more inefficient than using the function keyword. Where using a function is bad because they're called is when you use a function as a prop in a component. So, let's say you want to add a Delete button to the Fruits line, doing ` handleDelete()>` will be inefficient, because it's recreating the function many times (as an anonymous/lambda function). You would have the same effect as doing `handleDelete={function() { handleDelete() }}` , it's all about where it's declared in this case.
Your tutorials are great and your teaching shows that you have an in-depth knowledge of the topic. Though I am new to hooks, please, how do I dynamically load a sidebar nested lists from a database or an API. Kindly reply
It says no need for redux anymore in your description but with the context api you will end up re-rendering any component that uses your context every time the context changes. So this would work fine if you just have one or two things in your context but if you have a complex store you would end up re-rendering your entire app every time a value in your context is changed. With redux you don't get this unnecessary re-rendering. It would make for a poor preforming app. For a simple app this could be an ok replacement for redux. But in most cases the react context is a poor choice for state management in my opinion.
That's very true. Although, I could imagine, using "micro-stores" throughout your app, if it's a larger app. Then you only wrap a smaller amount of components with the Context.Provider. But, really the context API shouldn't be used for global state, but rather as a work-around for prop-drilling, like for a theme, or the current user, then it would only cause your app to re-render(completely) when the user changes or the theme, for example. The pattern in this video would be helpful for certain, but very specific use cases in samller apps, but not on anything bigger as it's going to likely have some performance issues, like u said.
@Luis Villavicencio I'll have to check out unstated-next. That being said your comment really doesn't have anything to do with this video or the performance issues of the way this video is portraying the context api. I'm not sure about unstated-next because i've not looked into it yet but the context api itself is good for certain things like user authentication and themes where the context doesn't change very often but for a state management solution it is still a poor choice.
Absolutely wonderful!!! Will show to my friends!!! By the way, I don't think it's a good idea not to declare an initial state. Oh, and, for each case you need to return all state and return the fruit or veg.
Well if this is a call you want done at initialization, you should put the rest call in a useEffect hook with the second parameters being an empty [] so that it only runs on initialization. This should be an async call which on completion, should use the dispatch function (pulled in from the useContext hook) to update the state of the store. Do NOT pass in the state as props to children in this same component (this will trigger an infinite loop). Instead, there should be another component nested, in which it only pulls out the store from the useContext api, this is where you can map over the results once they exist. Dan Abramov just published an excellent in depth article about this and can help a bit more than my simple explanation. overreacted.io/a-complete-guide-to-useeffect/
You can either do a single state tree, or break up the context into three different Context files. A single state tree is the easiest, but least efficient and it will get harder and harder to manage as the state tree grows. More context means you need three providers but it's a bit more organized and easier to manage with larger complex states
Other than your use of `function reducer() {}` instead of doing `const reducer = () => {}` , this was actually a reaaaaaly good intro to the store, context, dispatch, and reducers. You're using separate components and files, and you have a real useful example. Thank you very much for this, it's helped me tremendously!
〈evie.codes〉 thank you!
I’m curious why you say using an arrow function is better when there wasn’t a need for auto binding.
Anon Arrow functions generally cause a bit more overhead since they are recreated every time they are called instead of referenced every time like how a standard function works.
Sometimes I find them useful and convenient but if I don’t need the convenience, then I don’t see why not use a standard function.
@@WebDevProfesh Well, all your components at this point are functional components, right? So they're arrow functions, which aren't any more inefficient than using the function keyword.
Where using a function is bad because they're called is when you use a function as a prop in a component. So, let's say you want to add a Delete button to the Fruits line, doing ` handleDelete()>` will be inefficient, because it's recreating the function many times (as an anonymous/lambda function). You would have the same effect as doing `handleDelete={function() { handleDelete() }}` , it's all about where it's declared in this case.
One of the very few clear and direct tutorials on this topic. You got a new subscriber!!! Well done.
Thank you for this. The sound wasn't the greatest, but the content was 1st class. 👏🏻
Watched at 2x. Seriously underrated tutorial here.
Sushruth Sastry thank you!
Your tutorials are great and your teaching shows that you have an in-depth knowledge of the topic. Though I am new to hooks, please, how do I dynamically load a sidebar nested lists from a database or an API. Kindly reply
It says no need for redux anymore in your description but with the context api you will end up re-rendering any component that uses your context every time the context changes. So this would work fine if you just have one or two things in your context but if you have a complex store you would end up re-rendering your entire app every time a value in your context is changed. With redux you don't get this unnecessary re-rendering. It would make for a poor preforming app. For a simple app this could be an ok replacement for redux. But in most cases the react context is a poor choice for state management in my opinion.
Excellent comment. Glad that somebody mentioned the performance issue.
That's very true. Although, I could imagine, using "micro-stores" throughout your app, if it's a larger app. Then you only wrap a smaller amount of components with the Context.Provider.
But, really the context API shouldn't be used for global state, but rather as a work-around for prop-drilling, like for a theme, or the current user, then it would only cause your app to re-render(completely) when the user changes or the theme, for example.
The pattern in this video would be helpful for certain, but very specific use cases in samller apps, but not on anything bigger as it's going to likely have some performance issues, like u said.
@Luis Villavicencio I'll have to check out unstated-next. That being said your comment really doesn't have anything to do with this video or the performance issues of the way this video is portraying the context api. I'm not sure about unstated-next because i've not looked into it yet but the context api itself is good for certain things like user authentication and themes where the context doesn't change very often but for a state management solution it is still a poor choice.
Absolutely wonderful!!! Will show to my friends!!! By the way, I don't think it's a good idea not to declare an initial state. Oh, and, for each case you need to return all state and return the fruit or veg.
Really nice and clear tutorial thank you!
Could you make an example of calling reducers directly from a function and NOT from the render?
This is very helpful, I wish you shared the code itself as it would be very useful. Thank you so much!
are you in city concert hall
Increasing the speed of the video somehow helped reduce the echo for me :D
Lol working on my office. Will try and fix it
@@sushruthsastry2598 it works!
@@WebDevProfesh good content btw
Hi! Excelent video!, i have a question, where i should do an API REST call, and then pass the result to childrens using Context API?
Well if this is a call you want done at initialization, you should put the rest call in a useEffect hook with the second parameters being an empty [] so that it only runs on initialization. This should be an async call which on completion, should use the dispatch function (pulled in from the useContext hook) to update the state of the store. Do NOT pass in the state as props to children in this same component (this will trigger an infinite loop). Instead, there should be another component nested, in which it only pulls out the store from the useContext api, this is where you can map over the results once they exist.
Dan Abramov just published an excellent in depth article about this and can help a bit more than my simple explanation. overreacted.io/a-complete-guide-to-useeffect/
@@WebDevProfesh Thanks a lot, i have it more clear now.
@@WebDevProfesh This would make a lovely video :)
what's appen if we want to use 3 state in a component ? for example we need to get data from todos, users and for example maybe the color of the app ?
You can either do a single state tree, or break up the context into three different Context files.
A single state tree is the easiest, but least efficient and it will get harder and harder to manage as the state tree grows.
More context means you need three providers but it's a bit more organized and easier to manage with larger complex states
@@WebDevProfesh Too late hahaha, I use now one contex twith a single state tree if I have few data. But Thanks for you answer :)
great! thanks for this
could u post a the stackblitz or codesandbox please
Does anyone has this code on github or gitlab or somewhere i can download?
Can you send me the code link please
Redux: 😤🤬