State Management in React with Context and Hooks

Today's workshop is about state management in React with Context and Hooks. So I'm glad to see you all signed up and joined me for this workshop. So what is this about? I think if you're working with React you probably heard about state management from the beginning onwards and you probably have been confused and also reading out more about it every day because I think there are a lot of different topics in React state management.

When we started, or at least when I started working with React, I think everyone said Redux was the golden tool for state management, and often you would find at least if you were looking for a job like two or three years ago, you probably saw Redux as a desired skill for basically every company that worked at React. And also people are asking about React, so every time I did workshops people keep asking me questions about how to use Redux, how to implement it, why you should use it for state management or why not. And I think the discussion is still very relevant today. And even with new tools like the context API, it has become more and more relevant. Like, is Redux actually the best tool for your product? And should you be using it? So for today, I won't be telling you how to use Redux, but I will show you some alternatives and also how those alternatives compare to Redux.

A little bit about myself, so my name is Roy, you can find me on Twitter using the handle gethackteam, and currently I'm managing the engineering teams at Vandebron, which is a renewable energy company in the Netherlands. And I also work together with the Sailor team, and Sailor is an e-commerce API for actually more of an entire product, sort of comparable to what Strapi or GraphCMS is doing for CMSs, but then for e-commerce. It's also a really nice tool that is using a lot of React on the front end. And also you might already know me from some of the books I've written about React or React Native or talks I did about those topics, but also a lot about GraphQL, so if you're interested in that, please find me online. And also quite recently, I created this new book on creating full stack GraphQL applications, and it's both with GraphQL and TypeScript on the back end and also React and XGS on the front end, so if you're interested in those kind of things, yeah, you can find it here on this website.

So for today, let's go back to state. And before we actually go into details, let's also look at what state actually is because state can be a lot of things, and state often can also be living just inside a menu. So I think two years ago, I was creating a nice open source library for the city of Amsterdam, so also the city where I'm living in, and over there, we were working with state, of course.

We also created a component library so in that we also worked with menus and menu items inside such a menu. And the menu looks something like this. So you would have a simple menu that could be open or it could be closed, and whether it was open, the state went through, and we decided to display a submenu. And in this solution, we almost always pass state down. So you can just create a menu, and you pass state down, whether or not the menu's open, and then based on that, you will do something inside maybe a child component, you maybe render a child component.

And in this solution, you almost always use local state, so either a state in a class-based React component, or maybe if you're using function components, then you would use the useState hook. And I think for simple things like this, like having a menu, having a submenu, or maybe just a menu item, you always choose to use local state because it doesn't really make sense to implement something bigger, like Redux or the Context API or maybe one of those other tools that are around. But if you have a more complex menu, you already need to consider if you still want to be using simple local state in React. Because maybe you have a menu, you'd have a submenu, there's a menu item, or maybe the menu item inside the submenu is another submenu, so in theory, we could go indefinitely far.

And in this solution, it's already good to start thinking about state like how complex should my state be? Or how simple should it be? Because this could be an example of your menu. So maybe you have a hamburger menu for mobile devices. It could be open or it could be closed. So you still have simple state like open is true or false. But maybe you also have a child inside that could be open or closed, so maybe you also have state for the opened or closed child in there. So this is already starting to look a bit more complex, and especially if you want people to stay in the same state whenever they refresh the page. I think it's getting more and more complex, and those are things you should think about.

And also you might be using, if you worked in a component library before, you probably have been wondering about accessible components. So if you want your component to be accessible, you want certain parts to be highlighted whenever someone uses the keyboard to navigate instead of their mouse. If you would be in such a situation that maybe you also want to know which child is selected, so you don't only want to know if the menu is opened, if a submenu is opened, or actually which submenu is opened, but you also want to know which child is selected. And it goes pretty far, and it also depends on how far you want to go, because I don't think you need to define IDs in state to determine which submenu is opened, but maybe if you do want to do this, it already gets more complex.

And this is still something you can quite easily use local state for. But there's already something you need to think about if you would still pass the prop zone. And I think for these scenarios where you would have a menu with a menu item, or maybe a menu with a submenu, or multiple submenus and menu items inside there, I think it's probably straightforward to say you could just pass state down, you create local state in the parent components, and in there you pass it down as props. And in the parent component, you will manage the local state, you will make sure that the menu items are opened or closed whether or not the actions someone is taking in your application. But what if these components aren't menus or submenus or menu items? So what if these components are your entire application or maybe even routes inside your application or components inside routes inside your entire application? If you would be in such a situation, then probably you won't be using local state anymore because you want your state to be more diverse.

And when we talk about more diverse, I always think about the chessboard. So chess has been becoming more and more popular, I think, especially with all the Netflix shows and all the cool documentaries about it. So when you think about state, you can also think about a chessboard. So do you want your state to be simple? Do you want your state to be able to pass one field by one field or one component by one component? It's actually the most basic piece in chess is, or do you want your state to be more complex? Do you want it to be able to maybe skip components or skip fields to be able to go back and forth? Is that something you want your state to do? And if that's a scenario, then you won't be helped enough by using just local state with maybe you state hook or maybe even you seducer hook. That's a scenario you probably want to do more and you actually need more.

And with that scenario, maybe you could have ended up using context API or using use reducer, but before those functions were available, you probably ended up with using something like Redux or MobX, or if you're using GraphQL, something like Apollo. And all these libraries were created because React lacked certain futures and able to do state management. Especially in able to do state management effectively. So I think the context API helped us a lot by adding these additional features and I will show you how you can use it.

So the agenda for today, we will be mostly giving you a more introduction for about 30 or 40 minutes, and afterwards, I'll be working on exercises in breakout rooms. And then during in between, we can sync to look at the exercises. So depending on how fast everyone will go today, maybe we won't be able to do all the exercises at once. Luckily, we have the Discord channel, and I think I shared it in the chat already, and Lira was also there. So if you're not in the Discord channel, then please let her know through Discord, and then she can add you to the channel, and we can discuss the exercises even after today's workshop. So today's workshop will be mostly about the context API and how you can use it to do state management effectively in any React application. And actually, before a couple versions of React ago, it was advised not to use context because if you want the application to be stable, don't use context, it's experimental.

And I think it was a really good message because a lot has been changed to the context API. And some people even still say you shouldn't use it for state management, but I think it's also a bit of a more opinionated question to ask to a lot of people. But before this React version, it was actually advised not to use React, a context API for state management. And actually React was also telling you, or at least the React documentation was telling you, if you aren't familiar with state management libraries like Redux or Mopix, don't use context and just use these libraries because they are better tested, they're built by the community and they might have a lot of features that you otherwise wouldn't have. So how does the context API work? So the context API can be seen as sort of state or local state, or doesn't necessarily have to be local state, but could be local state, that wraps multiple components. So from multiple components, you should be able to access this context value and also to access functions to update the context value.

And creating a context can be done by the method createContext from React. And this method will help you create a context object. And a context object will hold multiple components, an example, like the context provider. So you always start with creating the context, after which you can create the context provider. So my context in this scenario consists of two things, so context.provider, and also context.consumer. And you actually need both in order to set up Context API.

So at first, you always need to create a context provider at which you'll feed a dynamic value. So this is setting the context value, after which you're able to consume it using the consumer component. And the consumer component makes the context value accessible, just as you see it here. So the value it puts in the context provider is the same value as you would read from the consumer. And this is all being done by using React Components, and there are other ways to also read the context value, but that's what I show you later.

But you might already think this looks familiar, right? Because if you have been using Redux before, you probably see that with React Redux, you have the same setup. So you create a provider, you add a store to it, and the store is actually your context value. If you look at the context API, and you have to provide a wrap your entire application. So from everywhere in your application, you're actually able to read the store value from a consumer. So the setup is sort of the same and the approach is also the same. So if you come from Redux, there isn't that much that is different in terms of setting it up. And also if you've been using React with Apollo or maybe some different provider for GraphQL, then you probably see that with Apollo provider, you do sort of the same thing. So you create a provider, you don't pass actually a value to it, but you pass a client to it. And with this client, you can connect with the GraphQL API. And also this provider wraps the entire application and from anywhere inside your application, you're able to access the clients. You're able to make calls to the GraphQL API in order to get certain data. So the setup is still the same. You create a provider. It wraps parts of your application or maybe your entire application. And then you're able to access these values from anywhere inside the component tree that you wrapped with it using a consumer. So hopefully this looks cool and also a bit familiar if you worked with React for a longer time.

So how can we implement this? So there are actually multiple ways to implement it, but this is like a very basic way to do it. So we already started. You first create a context and using this context object, you will get a provider from it, which you will feed a dynamic value. And inside the provider, you will put a component as a child to this React component. So the component that we'll see here is actually a child component, and the child component is able to consume our React context. So this is still very similar to how we do it with Redux and React, but also with other things like Apollo. We have a provider, provider has a value, and that value you can consume it from any component inside the provider. And you can also do this with hooks, because hopefully you've all been checking out function components, and probably for a lot of you, function components are your main way to create React components. So of course, with the context API, we can also use hooks. And it looks pretty much the same, so you would still have to create a context, and then using that context, you can call the useContextHook from React. So just as useState or useReducer, this is a built-in hook. So this built-in hook, you can pass it your context object, and then you can get the context value already using this hook. So you still have a context object, and you still have a provider to pass the value to, but instead of having a consumer component, you're actually been passing your context object to the hook, and then you're able to read it and use it inside your application. So I think this is a way, a way nicer way. It's maybe a bit less declarative, but still it gives you a proper grounds to actually use the context value. And also what I really like, you don't have to use it within a render anymore. So when having the consumer, you also need to access the value from within a render. And by using hooks, you no longer have to do this. So this is something I like from hooks in general and function components, but it's also a nice addition to using the context API, not having to get context provider value from inside a render, but just using a hook. So let's compare the two approaches. So the top one is where you have to consume from inside a render using the consumer component. Or the other approach is where we have to use context hook in which you'll consume the context objects. So in both scenarios, you still need to import the context object.

You still have my context consumer that you need to import from my context. And the other approach, you still have to import contexts object and use the hook to read it. So updating the context, we already saw that the context value is a dynamic value and it's something you can pass through it yourself. So updating the context can also be done by providing an update function to the context. So how did this work? So this is the thing we saw before. So you can create a context and then you will get a context provider that you need to set up and you can pass it any dynamic value. So what is this value? This value can be anything. And preferably it will be something that has to do with state because if we're using state of React, we already have update functions, we already have function that are dynamic and we're already triggering React to updates whenever we change something. So updating the context can be done quite easily if you look at how you use a useState hook.

So you would still have to create the context value, you have to create a local state value. So we will be using the React useState hook in order to create a state value. And the setup here is quite arbitrary. If you use a prediction, it looks a bit different because you almost never create a state object using useState for that you use reducer hook but more on that later. But it does show how you should approach this. So you would use the useState hook to create a state value. And a state value is something you pass to your provider. And also to your provider you would pass the update function for your local state. So your provider would exist of the state variables, but also for the update functions for your state variables. And by passing these to the provider, you're able to consume it inside your application. So if we're right here, you can see we have a context consumer. We're consuming the context value, and we actually be using the update function from inside our context to update the state value, which will then update our context value again. So by doing so, we actually make use of React's internal state management for local state. And we actually have been passing this into our context and able to use both of them. And by this, we get lots of approach advantages because we're already using internal systems of React. We don't need to create something. We don't need to use something from an external library. And this is all just React, which is also something I like. And while doing so, it's I think that we've reached the important part of, whenever you're doing this with React, you need to make sure that you separate concerns from each other, because if you approach state management like this, very easily we get to situations where you would have performance issues. And performance issues are probably, well, not that big of a issues because React itself is still performant and probably you will get very small lags, maybe even of milliseconds. So it isn't something really to worry about, but it's something you can prevent from happening by really separating providers from consumers.

So what do I mean with this? So with separating providers from consumers, you can have a look at this approach, you can actually create components that have just a context provider and that rep all the components. So your context provider can be a component that has the provider from your context object, but also has all the local state variables. And by separating providers from your consumers, you'll be able to really make sure that no unneeded updates are being done, because you already know probably, if you put a lot of different state variables in one React components, and then everything will update whenever something updates. That's something you want to prevent. So by separating concerns, you can make React more performant, you can also make it easier for React or maybe even Next.js if that's something you're using to know how components are aligned, how they work together. And it's also something that's quite interesting to see. And if we look at the DevTools for React, you have the profiler there, and in this you can actually see what's going on if you start separating these concerns. So whenever using the context API for something a bit more complex than maybe just having dark mode on or off in your application, make sure to separate those providers. And you can easily do this by just creating a new provider component, which is just a React component that has the provider from your context object. And in here you can see whenever you're doing so, you're just passing everything you put inside there as children. So the entire component tree that is not just one component, you just pass it in there and you have the children prop in React, which you can just use inside your provider and then return all those children. So this is also something it's not rocket science, it's something you, yeah, something you know if you're using React, the children component, something you just pass to it. And then you can easily pass the entire component tree. And also if we're updating context and we have separated those concerns, you also need to export your context object because your context object would live in your provider component. And then of course you need to export it. I usually use context to, we can use this context object to get all the values from our context, which is now just count and update context. And in this, you can just update it from any component inside the component tree. So we can see component here is now just one component with some HTML elements, but it could be an entire component tree. So from everywhere inside this component tree, we'd be able to use this use of context hook in order to get values from your context. And then you could just update them from maybe an onClick event or a button, or maybe programmatically whenever you do some, whenever you get some information from an API or from some other data source.

And for this, you can also create your own hooks in order to handle this. And to demonstrate this, let me open up a code sandbox for you. Code sandbox. I have some React examples here. Yes. So in here you can see, I've just simple context burning and let me go to my index file. And here, now I'll also share it in the chats, or maybe it's easier in the Discord channel. The code sandbox link, there we go. Yeah. So in here I've created a small example of using the context API with local state. And in here we can just refresh it to look the console warnings. You can see we have, well, just a simple counter with a button and it's the same code we just saw on my screen. So let me go here. Yeah, so what we're seeing here is just react. So I've imported react. You don't have to do that actually in later versions but it's, yeah, it doesn't break your code. And I'm also importing new states and create context. So what I'm doing here is actually creating a context value, context object using create context, and then I have my components, which is actually a place where I put my provider and in there I put local state, so count and set count. And then I pass second component into this, which is this one. And that's the one that's actually consuming this. And I also put it on this, maybe a bit more cleaner. This and then the second component, which is wrapped inside my provider. I'm able to actually get values from the context because what I'm doing here is using the use context hook and it could also restructure this if I want, so count, set count. Whatever I'm doing here is whenever I do the onclick event, I'll be using a value from a use context, which is set count to replace the state variable for counts. So this is just React and it's just combining use state, use context and set context in order to create a small, efficient local state management tool. Okay, some issues here. It's probably related to something else. But yeah, as you can see, it's quite straightforward. I also shared the link in the discord channel. So make sure to have a look and try it out yourself. But what I was getting to is, if you're doing this and you're separating concerns, you're also creating your own provider components. You can also create your own hooks to handle this. And creating a hook in React is probably sounding a bit more complex than it actually is. Cause creating a hook is, it's actually not really creating a hook, it's just following the standard to create a hook, which is also having a function. Ideally a pure function and append it with use. So whatever you put in there, use something behind it, you're using camel casing, then you're already creating a hook in React. So it's just as simple as that. So just as simple as that. On the left side you can see an example of such a hook and you can see here that I'm also extending or, yeah, I think extending is the best word, to use context hook from React. So whenever you're creating own hook in React, usually you're also extending existing hooks. And you can see here that our use context hook is returning values from our context. And this is something you will do like in this scenario, but maybe doesn't make that much sense because we're not changing any of the values in our context. But usually it would be also maybe changing values from your context, maybe you're combining multiple contexts together and it really makes sense to create your own hook and able to use this. And another nice advantages that you don't need to import your context object in every component that is using context, but you only have to import it inside the hook that you created yourself. So that hook is using, use context in order to mutate or get value from context. So on the right you can see, well, how you can actually use such a context hook in order to use values from the context. And it's almost the same as you would see with any other hook, you're just using your own custom hook in order to get values from a different React hook that you might have alterated or simplified or maybe you've extended them in any way. And this is something you can also see in, well, in the examples in the encode sandbox, you can see here how you can create such a hook yourself and how you can extend it. So maybe in here you could have done data fetching, other side effects you might be doing there. So these are all things you could do in there.

I think it's best always to keep these things pure because you want to know what goes in and what goes out. But maybe something else you could be doing here is combining multiple contexts. So this could be maybe my second context in case you had any. So it's also a nice way to combine things from multiple ways.

And something else that's nice, that I will tell you a bit more about is also using context together with the use-memo hook. And the use-memo hook is a hook you can use to memoise values. You might have heard about how to memoise React components, but you can do the same things for the Context API and also the values you pass to the Context API. So what does it look like? So usually whenever you have a context, it's the same as with local state. If you have local state in your parent component and you pass it down to children components, whenever you change something in your local state, all the children components will rerender. And it's the same with context. So if you have context value, you wrap components with it. These components are using something from your context. Context changes, then of course, these components will try to rerender. And with context, it could be the case that it also happens that components rerender when they actually don't need to rerender, because maybe the context value that they're using isn't actually being updated. So that's why it's important to also look if you need to use the useMemoHook, because you don't want updates in one part of your component tree to update components, or actually not really update, but rerender components somewhere else in its component tree when actually nothing changed for that component. So that's where the useMemoHook steps in.

And useMemoHook is something that you can add to your provider. So we have just a simple provider here. It's taking counts and an update function for counts from a localStateHook. So the useStateHook. And before we're passing this value to our provider, we're actually using the useMemoHook to memoize this value. And if you already saw to useEffectHook, you're probably familiar with the dependency array. Also, the useMemoHook has a dependency array. So using the dependency array, it will only update the value through the useMemoHook whenever the value for count changes. So if someone is using the updateCount function, I think functions are a better way to check for also in the dependency arrays because often they're not being compared in a great way. So it's always best to take values like a count, which is just a string or an integer because those things are easily being compared. But if you look at this one, you can see that the context provider value will only change whenever count will change. So if nothing changes to count, then there should be no reason for the provider or the context in this case to update. And this will also make sure that no components that are using this value are being updated unless the actual count value changes. So not if someone does something with the update count function or it would get paused, it would get called, it would get voided, this is function on one because that's why you used to use memo. Also, let me show you an example of this. Let me get back to here. So let me get back to the code sandbox. And here I can show you an example about what it looks like with the memo. The console for this. First, the app, clear the console. Oh. Yes. So whenever my application first renders, and it's something you can see. Actually, two components get rendered, right? So the entire app component, which is basically everything you'll see on this page, and also the component. And the component is basically this. So let me first do this without the memoized value. So whenever my component renders, you can see app renders, and component renders. And app is the entire application, which is everything you'll see. And component is just the part with the count and the button. So whenever I render the app, of course, app and component renders again. But when I'm updating context, just context changes, which is actually fine. Whenever I'm rendering app, my component also renders. Well, actually nothing changed for my component because count is still the same, but still, I'm rendering my app, and this component gets rendered. So by memoizing it, you can actually prevent this from happening.

So I'm just updating context. So you can also re-render my app without having my component being re-rendered because context is wrapping everything, and rendering my app shouldn't re-render this component because nothing changed in here. The count is still seven. I didn't change my context value because when I do app component renders, but when I don't change it, actually only app should render. So this is not the case in the first time because the first time we don't have a count, easily update, then both. But if you don't memoize this value, like this, then actually you will see whenever I render my application, every time it will also render my components, which could be strange, and it's something you try to avoid, and usually React is very good in avoiding this for you. But there are always edge cases and cases where they aren't. And you can actually prevent this from happening a lot by really just separating provider logic from consumers. So that's an important thing to do. And also by keeping providers small. So if you keep providers small, then there is a smaller chance that you're unnecessarily updating things.

So what if I have more complex logic? We briefly touched this point already. So in React, whenever you're creating state, you have a useStateHook, which is for a very simple local state, but you also have a useReducerHook. And the useReducerHook is a bit more complex because it detects two variables, which is the reducer initial state and it returns an array consisting of state and a dispatch function. So whatever it returns for state is actually the current state. And whenever you just mount your application, run it for the first time, the current state will probably be equal to the initial state that you feed to the useReducerHook. But it also returns a dispatch function. And the dispatch function can be used to update states. And how to update states will then determine on the reducer function. So your reducer function is a function that takes the current state, sometimes also take the initial state, but it takes the current state and based on the current state and whatever you dispatch. So whatever input you give to the dispatch function, it will return the new state. So these are important concepts to remember. So we have to use reducer hook. It takes two things, the reducer to return a new state and also the initial state. And it returns the current state often equal to the initial state and also a function to update the state which calls the reducer, which will then create a new state.

So what does this look like? So your reducer function will probably look something like this. So it's a function that takes the current states and the action and the action is, well, something I use this naming because I'm familiar with Redux. And Redux is based on actions. So it takes two things, it takes current state and also the action or whatever you put in your dispatch function. And based on whatever you put in your action, it's, which is, whatever you put in your dispatch function, it'll do something with state. So in case in your dispatch function, you provide this object, which has a type and a payload, which is very similar to Redux. And that's why I chose for the setup because I've been working with Redux for a longer time. So based, whatever I put in my dispatch function, which is a type increase. It'll do something with my current state based on whatever I've also put in my dispatch functions. So a payload. And based on this, it returns a new state. So the new state will be the count, the new count, which is the current count. And also, it's summed up the count that we have from our dispatch function. And also, it's, yeah, it takes the current state and it will do something with your current state. And again, I already mentioned Redux a couple of times. It can all look very familiar because Redux, typically a reducer in Redux will look something like this. So you would have an initial state, you would have an action. Based on your action type, you would do something and you will mutate state. So I took a lot of concepts that you have in Redux to make it more familiar, but also because Redux in general is set up quite efficiently. These are concepts you can still use with the Context API, but you no longer have to use Redux. Or you can use it together with Context. And if you want to use it together with Context, you of course need to create an initial state and a reducer, you pass it to a useReducer hook, it returns the current state and Dispatch Function. And those are things you would pass to your Context. So in your Context, you would have a value, which is basically the state that comes from a useReducer hook. And also functionalities that are called the Dispatch Function. So again, this looks very similar to what we did with the local, with the useState hook, but now it's a bit more complex and also a bit more efficient because we're really using Context Provider now to actually expose our state from the useReducer hook to our entire component tree. And if you want to update the value from the Context, you can just call the decreaseContext or increaseContext function, which on their end are called Dispatch Functions from the useReducer hook. And this is something I can again show you if we go back to the code sandbox. We would go here, we would have from Context with Reducer. That's probably the one. So in here you can see we have a bit more complex setup so we can increaseContext, we can decreaseContext. And whenever I push one of these values, it will actually dispatch a function for my useReducer hook, which is something you can see in here. So again, I have a ContextProvider, I have an initial state, I have a Reducer Function, and both I will pass to the useReducer hook. That on their end will do something with these values. Okay. And in my ContextProvider, I have set it to value for my Reducer state, that's the value for my context. And also I've put the Dispatch Functions, which are wrapped in a different function. So this is also why it's good to separate provider context, provider logic from your actual consumer because in here you can actually dispatch things. Maybe you can have side effects, maybe you can dispatch and then based on whatever comes back, you can take different actions. So these are things you can do in your ContextProvider. And again, here you can see from your component, which is consuming the context, you can just use a UseContextHook or you can create your own hook, which we saw before, which you'll also do in the exercises later on. So this component here is, yeah, being able to click functions that are coming from the context. And based on that, it will do something with the context value. So it will either increase or decrease it. So just as easy as that.

So what about debugging? So one of the nice things about Redux that it comes with a lot of functions for debugging. So unfortunately, the context API has now built in debugging, but of course you could use a simple console log or console table things, and also wrap your dispatch functions with other functions. So you could easily create your own hook, having not really having useReducer, but creating and extending with your own hook, having usedReducer with logs, and then just extending your dispatch function with something that logs it. And then from you as a consumer from this API or from this application, you could just call the useReducer with logs from a hook instead of the useReducer hook, and to already have a dispatch function that allows for logging. That looks like something you can see on this example. So make sure to go to the code sandbox and see what it will look like in order to really use this. And this one is a component that's rendered. You can actually see that every time we do something, it'll actually log what happened. So this is a console.table. Not too many people know about it, but you can actually log things in the form of a table instead of just logs. Actually, a quite nice feature of JavaScript.

So what if you want a global context? Because that's probably also what you would need if you really want to have state management for your application. You would also want a global context. And you can do this by, again, separating concern from your providers into different provider components. And here you can see, we can recreate different providers per category. So this could be an e-commerce application. Maybe you would have a provider for products context, you have one for categories context, you have one for your cart or for any other checkout progress. And then you would have a global context which is actually wrapping all these different context providers. And your global context, you can export it, you can pass children components to it. And then maybe when you set up your application and you're using something like React router, you can have the global context wrap your entire application. So this could be the setup that you actually be using here. You can actually have to global context have it wrap your entire routing. And then from any component, like products or products detail, you're able to actually get information for both the products context and also from the categories context. And then from any components, you're basically able to get the information something. Okay. In a similar fashion like we're doing here. But more about this because this is something you also see in the exercises.

So to summarize, you can use context to pass data to the component tree. And you can also use hooks for this. So it's so that you easily access this context from anywhere in a component tree. So you can use a use context loop to get values from context. You can also use a useState or useReducer hook to actually give value to the context. And also, it's important to understand context is not a solution for every state problem. So context can be a solution for your state. But it can also be used in different ways. You will see people using it for sort of local cache. You see other people using it for teaming, for maybe component libraries. But you also see people using it for states and even global state, not really global state because global would imply you can use it anywhere, but more like application state. So I would say global state is something you share with an API, and global state application state would be something just for API. So context could definitely be a solution for that.

And if you want to learn more about this, be using the rest of the workshop to create exercises for which I'll put you in breakout rooms, I would also make sure to find the code sandbox link here and also find it in the Discord channel. So you actually be able to play around with the context in an isolated solution, isolated place. And then in the exercises, I will show you how to actually do this more in detail. So the exercise we will be going to my GitHub, in which you can find all the repositories that I work on. And React Context Hook is not the one. It is the React Context Hook workshop one. So I will also share the link with you in the Discord channel. I will also share it here in the chat. I can find it. Let's see. Okay.

So what we'll be doing now is I will first show you more about the GitHub repository. Then I can take maybe five minutes to answer questions from the chat. And then I'll put you all in breakout rooms. Let me see how many people we've got right now. Zoom. It's nice how easily you can lose things if you have too much going on in your screens. So the Zoom is somewhere here. I'll see here. So we have 58 participants, that we're putting you in, I think, 10 different breakout rooms in which you'll be then with four or five people. Maybe six to work on the exercises. And then I will regularly check in with everyone to see how you're doing. But for now, I'll show you how to set up this one. So you would be going to the exercises link which I also showed in the chat. And in here, you can just as easily, you can go just anywhere. So I usually keep my codes in this directory because I used to be using Atom as my browser, not browser ID. So in there you would just do git clone and put in a repositor URL and it will be set up. And then you can just do yarn and yarn start and it will install everything in order to do the exercises. Any exercises are listed down here and there are 11 in total but also some bonuses. So I don't expect you to be able to do everything today unless you're really fast and maybe we are really fast and that would be great. But if not, then we still have the Discord channel to discuss later on. With that said, make sure to go to this repository and clone it. So you would have a local version of all the exercises and in here, all the code can be found. And also it will be using an API which is being fed by this one. So it's using a local API. So it's not that complex but make sure to get it running. And if you don't get it running, please don't use the chat now to ask questions but wait until you're in a breakout room so you can ask the questions to a smaller group.

Let me go to the chat and see if I can answer some questions. Yeah, I'm about to start an editor with Atem in these but I haven't been using it for a long time. So I think it was my first real ID when I finally got rid of Notepad+++. So good times in the past. Let me see if I can find some questions to answer. I see people are asking about other things for state management, sharing the code sandbox, which is good. So how do we avoid having many different providers? Yeah, so I think these are questions like would you pass down dispatchers and then exporting action creators? It's something that's nice if you have a bigger application. If you have a smaller one, maybe you shouldn't do that. But it wouldn't matter that much. I think it also determines a bit how you want to structure things and how you work together as a team. And also what's your starting point. I think it would be fine to just start out by passing along dispatcher function. But yeah, ideally, it would be nice to really create action creators. So, yeah, we also have questions in Discord. I will try to answer them in there as well. So for now I will be putting you in breakout rooms, but also you've been listening for me for about an hour. So also make sure to give yourself a short break. So let me create a breakout room. First of sharing my screen.

Hello, so how did everyone do in the exercises? I thought it was good to spend the last 15 or 20 minutes we have together on some Q and A. So if you have any questions or maybe some exercises that people already got stuck at, then we can spend this time to have a look at it. So feel free to unmute yourself or use the chat if you have any questions or have specific exercises that you want to discuss.

So my question is a bit of a refactoring question. So in the reviews context, you either can get all the reviews and then can for each hotel, you can select the list of reviews that are associated with this hotel, or you can fetch the reviews directly for this hotel. There are bits of pros and cons between the two of them. And I know it's not the scope of this session, but do you think there's a performance issue or a solution might be better than the other?

Yeah, so there are multiple ways to handle this. So you need to make sure that you never fetch data that you're not gonna use. I think that's one for starters. So what you can do and what we also showed in, I don't know which question it was, which you did in question eight. Or maybe you already did it before. And so at least in the question, so I don't know if everyone knew, but there is also different branches for every solution. So that's something you could, if you've got stuck, you can have a look at it. But if I leave maybe in exercise five here. No, maybe someone else knows. But there are so many solution exercises where the data fetching logic is inside the context, but the function to start fetching the data is in the component that is using the data. So that will make sure that you don't fetch data that you're not using, because it's something you want to avoid. I think in general, you never want to start data fetching from a different component if you're not triggered with a function and the component that's using the data. Because it gets very confusing otherwise. Yeah. I don't know if that answers your question. Yeah, yeah. Thank you. But it is something, yeah, so performance is something to think about when using context, because, yeah, if you don't split things up correctly, then you would end up in a situation where you would get performance issues because you fetch a lot of data, you bring together a lot of stuff. And also React will re-render if you change something in context unless you set proper boundaries. So it is something to think about indeed.

Can you show your screen and go over your solution to see how you did it? What do you mean? If you can go through the solution and explain, you know, we did it, but explain clearly why you did it. For which question? I can do it, but then you need to let me know which questions. Oh, sorry. Question three and four, maybe. Okay. Question three or four. Yeah, definitely. Yes, so question three and four. So question three was about get the reviews from the hotel, from the rest API. Yeah, so let me see, where's the terminal. French. Okay, so for question three, we contribute for this hotel, so you can note those screen was in detail. So there's some styling here, which you can ignore. So this one was still two parts. So I want us to use effect to get the data for the hotel. So guess for hotel, which would also only need to get if the match parents ID is set. So this is if you have HTTP localhost 3000, slash hotel, slash one. So here one is match that parents with ID. And basically the first user factor. And then it's the second user factor based on the hotel ID to get to reviews and it also has its own local state. So typically you want to have different user factor for different effects. Cause every side effect should have its own user factor because then you can easily separate concerns. So in this scenario, what you could have done is indeed have the same one because they're both using match parents ID but in case maybe match parents ID is undefined or something, then you don't want to have them in the same thing. And maybe also this is an ID that doesn't exist.

So people could just put crazy shit in here. Like maybe this. It probably isn't ID you can find in the REST API. So that's why it's better to separate the concerns. And then they both have their own fetch function. They both set reviews for the review and this one will set hotel. And this logic is something you also could have put in maybe a different look, or at least the data fetching because it's mostly the same, but the results are different. But that's about question three.

Question four, let me check. Yeah, so in four, it will get interesting because here we're creating a context. So what you should have done for this one, hotelsContext, so it's probably in hotels. Yes, you would create a context here using the createContext method. Then we create a context provider, which is using the hotelsContext which we created here to set a provider. And if they're a certain provider, they come from local state. So it's loading error in hotels. So basically what I did, these things are previously here, all these things, basically all this. So before this was here, it was in the hotels component. So I set my local state, I did my data fetching, and based on that, I will use these values here. But now instead, what I'm gonna do is create a context for it, so you could delete all this. You create a context file, you set the local state in here. So it's just like copy-paste, you do the data fetching, and the results for this is you don't display them, but instead you put them in a context. So they also become context values, and our context is something we export. So in hotels, we can import the hotels context. And in front of context, we can get loading errors in hotels, which previously we got from local state, but now we get them from the context, and the context gets them from local state. Basically, we just copied a lot of logic from a hotels component to the context, making this component more dumb, and also easier to refactor and to replace, and having the context have all the logic in there.

But what I was mentioning before is, what you actually don't want to do is this. So the use effect is actually something you don't want to do in here. So later on, in one of the exercises further along, it will be shown that to fetch the data, what you actually want to be doing is also passing this function here. So you want to have the data fetching function in your context, and then from here, you just do this, so fetch data, and then you would have a use effect hook. Dependency array could be empty. It could be hotels.length is zero in the beginning, or actually non-existing, so thank you, editor. And then fetch data. Actually what you want to do is this. So... So what it does, so the context has a logic to fetch the data, but your component decides when it will be fetched. So in your use effect hook, you will decide you want to fetch the data. Whenever you fetch the data, we call this function from the context. Oh, not that one. Context. In the context, this function will be called, and when it will be called, it will set the hotels, it will set loading to false, and it will set error to true in case of an error. And then the context will be updated. So hotels will change. First it will be, so first... Or initial render actually. So initial render... Is this one. And then after we set the data fetching, hotels will be... Some array with data. So something like this. Did that answer your question? Yes, thank you.

Okay, good. Yes, do you have a question, Paolo? Yeah, sorry. I think it's a general question but I think I don't understand what is the best way to manage the errors with a context. I think it's so difficult for me to understand what is the best way to do this. Yeah, so it really depends on what kind of error and how you want to scope your error. So if it's a data fetching error, you could put the error on the context value. Do you have other kinds of... I don't know, what kind of errors are we talking about? Yeah, for example, in this way when we can add hotels to the list and for example some fetch was failing with the hotel list, for example, something like that. Okay, yeah, I would just put them on a context and then, so if you have a use-reducer later on, it will be easier to see what is going on and what's the actual error. Oh no, I'm talking about, for example, the estate of error and set error in the catch but I think that in some projects could be some difficult for understand what is the best way to maintain the errors or for example, if we have different list of data and we have different kinds of errors. Yeah, so every context would be specifies to a certain things, you would have a context for review, a context for hotel and every context can have its own errors. And I think there you should decide if you want to have errors for everything that goes wrong, if you want to have like a global error, that's also something you can do. But I think it's more of a general state management question. So what kind of errors do you want to put in there? I think it's also up to the side, like what do you want to display to your users. So if you want to show your users there's an error and that's it. And you can just have like a global error per context. If you want to show your users what's going on, then you could have an error per part of the context. So if you want to show your users, I don't know, maybe an email should be, an input field should be filled and also they should fill something else and they should fill all the things. Now you could also have specify your context, like you have an input field for email, an input field for name, an input field for a body and then have an error per field or just have the global error. So it really depends on what you want to display. So context, what you put in there should really be what you also use to display to users. So if you don't want to display, breaking down errors, then you shouldn't have to do it, if you want to do that, now you can just use the context for it. Does that make sense? Yeah, it makes sense. Yeah, it is the question. If it's better, for example, have different contexts to do this, for example, a global context and refresh this global context if we need. Okay. Cool.