Programming Stuff

Redux - How does Redux work?

2020-08-30T16:26:00.005-07:00

Now that we have a pretty good idea of the major problems Redux was created to solve, namely props drilling, state sharing, and global state chaos. Let's take a look at how it actually works. Well the name Redux might intimidate a lot of people, as names that end in 'x' tend to do, it's actually a fairly straight forward concept and process. Earlier, we learned about both the benefits and perhaps more importantly the rather crippling drawbacks of having a single, unrestricted global state that's accessible by all our components. That being said, one of the core concepts of Redux is that we have one central, global state called the store that all our components can access. Now this store is essentially a big J-son object that serves as the single source of truth for all of our components. And in theory it can hold any kind of data that we need it to. Although in practice there are some things that are better off without it, but that's a discussion for another time. So for example our Redux Store can hold data about the users, such as whether or not the user is logged in, the user's name, age, and bio, and what other data we might load from the server.

It can also hold things like a list of products on an e-commerce site, or a list of articles on a blog site. Basically, anything that we load from a server or any internal application state that we need to keep track of can be put into the Redux Store.

So the next question here is.. Since Redux uses a global state, how does it prevent the chaos inherent in this approach? Well, the problem with a global state isn't the fact that it's global per se, the problem is that there's no good way to control the excess and modification of this global state by pretty far flung parts of the application. This means that with an unrestricted global state, any part of our application can make whatever changes it wants to the global state basically without any restriction whatsoever. So we'd be relying on all our components to be good stewards of this state and change it in predictable ways, which from a software development standpoint, is a very naive assumption.

So in order to see how Redux solves this problem, let's take a look at the two other pieces of the Redux flow. We've already talked about the Redux store, which contains the current state of our application, but in addition we have Redux actions and something called reducers.

Let's discuss both of these intern. Redux actions are j-son objects, consisting of two things, an action type, which is basically just a string naming the action, and a payload of additional data. The purpose of redux actions, is to explicitly define the different events that can occur in our application. So for example, we could have an action with the type: user data loaded, with a payload that contains the actual user data that we just fetched from the server. Or we could have an action with the type: item added to cart with a payload that contains the idea of the item that the user just added to their shopping cart. Now obviously the number of possible actions in an application can be pretty large, but the point here is that we're explicitly defining them, instead of just leaving it to chance. So that's actions,

reducers on the other hand are Redux's way of specifying what should happen to our Redux store, our central state, when a given action occurs. So using our example from before, we might say that when a user data loaded action occurs, we set the user property in the Redux store to the user data that's in the action's payload. Or when an item added to cart action occurs, we add whatever item is in the payload, to the array of items in the shopping cart property of our Redux store. So the key point to know here is this: our components are only allowed to make changes to the state by triggering these predefined actions and the only changes to the state that are allowed to take place in our application are the corresponding changes that we specify in our reducers. This all gives rise to what's referred to as unidirectional data flow, in other words, we end up with a cycle that looks something like this: the UI triggers an action, that action is reduced to get the new updated state, and the components in our application get read only access to that updated state. We'll go into more detail about this in videos that follow, including what all this looks like in code and how components can access our store and trigger actions.

Redux -Why do you need Redux?

2020-08-30T16:20:00.011-07:00

we going to be looking at here is something called Redux. Now, before I give you the details about what Redux is and how it works, lets take a look at the problem that Redux seems to solve.

This should do a good job of answering one of the most common questions that people tend to ask when they learn about Redux, which is, "Well, why should I use that?" So, the question that Redux aims to answer is an extremely common one, and that is, "What's the best way "for us to manage state in our application?" This can often be one of the hardest things to figure out in react applications, since there are so many options each with their own pros and cons. For example, we could take a rather extreme position and have one central state contained by the route component, and then have it pass down pieces of that state to all its children. But this is usually a pretty bad idea. Since once our app reaches any kind of size, we'll have to deal with an immense amount of what's called props drilling, And that's when we have to pass props through a component that doesn't actually use them but just passes it onto its children. Now, I've seen apps where there are many levels of props drilling. The root component passes props to a page component. The page component passes these props onto a section component. The section component passes those props into a list component. And finally, that list component passes those same props down to a list item component. Now, not only is this ugly, but it can be very frustrating to troubleshoot since sometimes a developer can inadvertently break this prop chain by mistyping the name of one of the props or something like that, which leaves them wondering why some value in one of the child components is undefined.

So it's clear that a single state contained by the root component is probably not the way to go. So, what if we went all the way in the opposite direction and just had each component manage its own state? After all, this would avoid the problem of props drilling,

but now we run into another problem. What if components that are far away from each other in the dumb need to share data as they most likely will? For example, what if somewhere down in the component tree we have a button component and we only want that button to be enabled if all the pieces have a form component somewhere else in the component tree are filled out?

Well, really our only choice here would be to hoist the state all the way up to whatever parent component those two child components have in common.

But this leads to a rather unpleasant situation where you're never quite sure where in the component tree to find the state for a given component. It could literally be in any of its parents depending on the needs of the rest of the other components of the app. So, it's clear that the two choices that we just went through are much less than ideal. But what other options do we really have? Well, a pattern that would seem to solve both the problems we've seen so far; the problem of props drilling and the problem of how to properly share state would be to have what's referred to as a global state. A single centralized state that all components have unrestricted access to. So, there's no props drilling because components can just access whatever data they need directly, and there's no problem sharing states since by default all components share the entire state in this situation.

Now, this might sound great in theory, but in practice it can be a nightmare. And here's why. There are no rules for how to actually interact with or access the state. So, what you end up with and all, but the most disciplined code bases is an application filled with these transient hard to recreate bugs that occur because of inconsistencies in the state. Just trust me here. An unrestricted global state is generally not something you want. So then, with the exception of the lack of rules and the subsequent chaos when using a global state, having a global state does solve the other two problems we mentioned. Sharing state and excessive props drilling. So, what if we were to take this idea of global state and solve its main problem by adding some strict rules and organization to it? Well, in fact, that's exactly what Redux aims to do.