Welcome back.
I know we're all getting excited to start coding but I want to do one last video before we actually
start working with some code which is the exciting part.
But again I want to emphasize that before we use anything we need to understand why and why we would
need something like redux. Right now, online, and with any company that is working with react, most of them
have also redux.
So you'll hear react and redux app mentioned a ton when you're watching tutorials or working with react
and that is because they go really really well together.
Let's just go over a few things about redux that we want to make sure we learn and a bit of warning
here.
Some of the stuff might go over your head or maybe a little bit confusing but I want to show you these
slides first because after we go through the redux coding we are going to come back to them and make sure that
these principles are applied and they make sense to you.
So bear with me.
Trust me it's all going to make sense by the end.
Why do we want to use redux? As we mentioned before, redux is really really good at managing state especially
large state.
So redux is a library that we would want to use if our apps get bigger and bigger and bigger and they
have larger and larger state.
Remember we want to use tools based on the problems that they solve and redux solves the problem of what
happens when react apps get really really big and using just "this.state" just doesn't make sense
anymore.
It gets more and more complicated.
Remember react is what we call a view layer.
It's really good at the view side but not necessarily at managing state.
So use redux when things get really really complicated.
The second point is useful for sharing data between containers. And this is another thing with when projects
become large, when they need to start sharing state between containers.
With react this is actually a little bit difficult and you have to move the state up one layer so that
you have a parent that can share a state between the two.
But with redux this becomes really really easy as we're going to demonstrate in our coding section.
And finally redux has predictable state management using the three principals.
Now what are the three principals? These three principals in redux are going to really really make sense
at the end, but I want to still introduce them to you so that we're aware of them.
The first one is the idea of single source of truth.
And this is a fancy way of saying that we have one single big object that describes the entire state
of the app.
Remember this? We had one massive state object that describes everything within our app.
So we have our single source of truth because react reacts based on whatever the state is.
We can just have one big object that describes how the app should look and react will take care of it.
The second principle is the idea that state is read only and this encourages something called immutability
which is not modifying the object and it prevents unexpected errors this way.
So the state object that we will create with redux will actually never get modified.
And instead we would create a new state after each action is taken by the user. And then finally the
third principle is the idea that changes are made only using pure functions, something that we've talked
about in my previous course.
The idea that a pure function is something that receives an input and always returns an output that is
predictable.
If we enter the same input 1000 times we expect that function to have the same output 1000 times. Using
these principles,
Redux has some new words that we're going to introduce in our vocabulary and we're going to be comfortable
with them by the end of this section.
The first one is action.
An action is something that a user does such as clicking on a button or a dropdown menu.
And what happens in redux is as soon as a user clicks on something a button and creates an action.
It goes through something called a reducer and a reducer is simply a function, a pure function that receives
an input which is the action so the user just clicked on a button and creates an output and this output
is the state or the store as we call it in redux which is the entire state of the app.
So as it goes through the function the store gets updated and react because it notices this state change
makes changes to the view layer.
Again these are wars that we're going to encounter as we start coding along.
Now why do this.
I mean can we just have an action and then an action happens and then we just make changes.
I mean that's how something like JQuery used to work.
And yeah it looks more complicated doesn't it.
Adding all these steps beforehand but as you can see above if you have tons of actions happening which
with modern apps that are very interactive, this happens a lot where the users scroll action and then
the clicks a button and then highlight something and so on and so forth.
You see that the more and more actions we have the more changes we have to make and those changes might
trigger other actions which trigger other changes and so on and so forth.
And it can get pretty pretty complicated as you can see in this diagram.
Well with redux we make sure that all the actions go through one reducer.
Everything flows through this function and through this function it always, because it's pure, returns
the same state based on the action and updates the store and this store now which represents what our
app should look like, makes changes.
So kind of funnels all these actions into one reducer so that everything is predictable and nice. Again,
one of those things that's hard to really explain without encountering the problem first, which we will
get to. Now, redux,
and I want to teach this just for historical purposes, uses an architectural pattern called flux pattern.
Architecture and software is used as a way to make sure that we're able to solve problems in a logical
sense and in an organized fashion.
And this flux pattern which inspired the library redux, has this idea of having an action and then having
a dispatcher that dispatches this action to the store which is our state which updates the view.
And it's one way data flow - everything flows one way.
If the view gets updated we go back to the action and again goes to dispatcher that dispatches the change
to the store and then to the view.
And this was a pretty revolutionary idea.
Because before that we had something called MVC or model view controller.
And you may have heard of it. It was quite quite popular. The idea with the MVC pattern is we have an
action and that action is read by a controller.
So again another javascript file that looks for actions, a user clicks on a button and based on whatever
the controller says, we update the model or the data
in this case.
So we can think of it as state. We change something in the model and then it updates the view.
Now the problem with the MVC pattern is, well this diagram over here. Wwe have the controller that changes
different pieces of the model.
And this model can change the view that can trigger another change.
And that model can change another part of the view and so on and so forth.
And we have this thing that we saw before. We have the craziness of actions and making changes. All these
arrows just criss-crossing and not looking very nice.
And although it might not be bad when your apps are smaller as your apps get bigger you want to do something
like this so it's logical and makes sense.
And that's what we want to do with architecture.
We want to architect our apps in ways that as they grow although we may add a few things in the end
everything is easier to reason about and understand.
So we have the flux pattern which enforces a unique directional data flow.
We have the MVC pattern which could definitely be improved. If you get anything out of this video,
the one thing I want you to understand is the idea that redux, at the end of the day, is pretty much the
same as "this.state" in react. With redux we can replace "this.state" and theoretically remove
all of "this.state" from react and have it all happen inside of this redux library, which again we're going
to do.
But one caveat.
You could technically have redux with the state but also still keep a little bit of react state in a
component.
Redux doesn't replace completely the "this.state" or "this.setState" in react.
You can still use them together and I'll show you when you might want to do that when it's a good decision.
But like I said before without having gone into any of the code of redux this might look a little bit
overwhelming and confusing.
I promise you that we're going to come back to
these diagrams and things are going to make sense by the end.
Before I throw code onto the screen I want to make sure that you have some principles and concepts that
we're working from.
All right.
I know where you're thinking. Andre' I am sick and tired of the slides even though they have this cool
grading color I need to see some code because I'm getting bored here.
Well you know what, your prayers have been answered in the next video.
We're finally going to start writing some code and get into some fun things.
I'll see in that one. Bye bye.