Original subtitles

Now that we've finished building our React Project Monster's Rolodex, we are actually going to start

building our final project, which isn't fully fleshed out e-commerce platform.

We're going to expand upon all of the topics that we covered today doing this monstrous Rolodex.

But we're also going to use more patterns and more of the fundamental libraries in the react ecosystem

that large companies are already using to build their Web applications today.

So let's take a look at what we're actually going to build.

This is our final e commerce project.

We're going to have navigation and routing.

That takes us to different pages of categories of items and from these items, we're actually going

to be able to add them to our cart.

And from our car, we're actually going to see these things directly update.

And from this car, we're going to be able to check out increase or decrease these items again and see

the live changes in both our checkout page and our car page, remove items.

And actually integrate with a stripe API so that we can handle payments.

Now this is actually going to be a test version of Stripe because we don't actually have items to ship

and we don't actually want to process real payments because this is just a portfolio project.

But the matter of switching it is simply a change in the actual stripe website it you're going to actually

learn what it is to actually build using the stripe API.

And beyond that, we're also going to integrate with Firebase to handle our authentication and our storage.

So with Firebase, we're actually going to be able to authorize our users using Google so that we can

sign in with our Google accounts.

And once we sign and we're also going to provide a sign out feature.

And a sign up and sign in with email and password feature, so it's going to be a really fleshed out,

fully complete e-commerce platform, just like you would build for real e-commerce company.

Now, before we begin, there are a couple concepts that I want us to go over with react so we have

a better understanding of what it is that reactor's actually doing for us.

So in order to begin, we're going to have to go to our original Monsters Rolodex application and now

we're going to look at our actual developer tools and we're going to look at our dorm so we know that

our dorm is our representation of our actual application.

Inside of our app component that we built, we have that each one, we have that input and we have this

card list.

These are all elements that are children of this app and are inside of our card list is those children,

these card containers.

Right.

If we were to actually look at this from a very basic representation, will see that it actually looks

like this tree.

Right?

This is our app.

That was that H1 title.

This was that search box.

This is the card list.

And that card list has children, which are these card component notes.

So this tree actually represents our actual dorm.

However, in order for our actual dorm to update any of these elements, it's actually extremely slow.

So it takes the dorm a lot of energy to update any of these elements.

Now, what really does is it copies this actual dorm tree and it makes it in JavaScript, just like

we see when we write RSX.

RSX also is just JavaScript that returns what looks like these HTML elements.

So what we'll do is it'll completely copy this actual dom.

Except this, it will call the virtual don and the virtual dome is, as I mentioned, just a complete

copy of this actual dome, but in JavaScript.

Now, in our application, whenever we update any of the data that ends up being rendered in our components,

let's say our fifth monsters email or its display name changes.

Well, Riak doesn't actually want to virender the entire door, it only wants to affect the thing that

matters, which is this note.

So what we're going to see happen is react actually copies this virtual dom again, except this time

it's going to apply the changes to the data that got updated.

So the monster number five, it's going to change that.

The name it's going to change the email, a current.

However, we actually changed it and then it's going to apply those changes to this virtual dom and

see what that element that got affected would be.

So it would end up actually being this element.

So it'll actually make the change here and then what it will do is it will compare this new virtual

dome to the old dorm and it will see that this is actually different now.

Right?

This and this are different.

So then it will know, OK, let's actually apply the dorm changes to this element.

And when it does that.

It's actually way more performant because it doesn't have to mess around with the dam unless it knows

exactly what elements it needs to update, and that's why React is so fast, because of its ability

to build out these virtual dams and then compare and contrast against the real dam to see what's changed

and then make the appropriate updates to exactly the right notes.

Now, can we actually see this in action while we definitely can, what we got to do first is we got

to go back to our monsters application.

And we're going to make a couple of minor changes first, so in order to see this in action, we're

actually going to add a new field to our state, our data, and we're going to call it our title.

And what we're going to do is whenever that user search happens, we're actually going to also.

Have it so that our title updates with whatever it is that our user typed in.

So instead of filtering out our monsters, what we're going to do is we're just going to display the

monsters, right?

We don't want that search feature for now.

We're also going to add in this title, feel that we've just added to our state and instead of monsters

Rolodex, I want to show the title.

So what happens now is that whenever we type, we'll see this title, right?

We'll see our title update.

Now.

If we enable inside of our additional rules, let's just add actually our rendering.

What will see?

If we enable paint.

Is that this website will flash green in all the areas that are getting updated, whatever DOM elements

are updating, it will change it.

So if we refresh, we'll see the whole page fostering because it's mounting and rendering everything

for the first time.

Now, let's say we actually start typing in this.

Well, when we type this, we'll see that only this title is getting updated, nothing else is getting

re rendered because Riak knows that the only thing that needs to update is this title.

This title node is the only component in our DOM that needs to be rendered.

It doesn't touch anything else.

And that's what is so great about reacts virtual dom and its efficiency when it comes to deciding what

in our dom to render.

Now, let's go back to our application and let's undo this right, so we get our app back to the state

that it was before.

So let's undo that.

Let's remove this title field.

Now we know that we have our monsters array on the state of our app, and we passed that after we've

modified it right after we create a new array, but based off of this data array using our search field.

To filter out the monsters that don't match and we pass that into the card list.

And then our card list component.

Is the one that will then map out using the data that got passed into it.

The new cards, right?

So if we were to look at this thing again, except let's just focus on our application, right.

That Monster Zarei sits at our app, it gets passed in the card list, and then it generates these components,

right.

And these end up being all of our actual components that we view.

This is actually all of our views.

What react does when it's actually rendering out the application is that react is based off of this

data that we saw.

Right, the data from the state of our app component, the monster array.

Gets past to this cardless component, which then renders out these components, these card components.

If, for example, whenever we type in our search field and we update and change that filtered monsters

away, right, that gets passed into our Carlist, then react actually re renders this entire tree because

it knows that the data at this point has changed.

So if it's passing that data down to its children, the children are what is going to need to be re

rendered.

However, if we can imagine that we moved the data of our monsters and our filtered monsters, all of

this into the actual cardless component instead.

So if we took all this and we moved it into here so that the data actually sits at the cardless level.

Well, what happens if we were to do that same thing, if we were to modify that array at this level

right, instead of it sitting here, it's now here and then we modify that array?

Well, these children would still get Virender right.

React would re render any part of the tree below this note because the data that's used to generate

these views actually sits here.

But anything above it, the parent, our app and then the siblings, right, the search box and the

title would not render react, has no reason to render anything above this note because the data only

affects the children below this note.

This concept is called unidirectional data flow.

So in react, that idea of building views from data is actually very key as to why react so predictable.

So here is actually a quick image of what that looks like.

That data is in our state, right?

Our monsters array, our search field.

All these things react, uses that data to build out the views, as we saw in our Carlist example,

right where we mapped over that monstrous data to build out these card components.

And then if the user does anything or the application does something.

From the viewpoint, right, it'll trigger these actions that update the state.

Now this action, we can see it as something like when we type in that search field, when we type in

that search field, that action is trying to update the state.

Right.

The data that we have, it updates the search field and then that search field updates that filtered

monsters array and then that again gets passed and used to generate the views.

Now, that data always flows in this direction.

It always goes from the state of our data to building out the views and then from the views, there

might be interactions that make actions that will update the data.

Again, this idea of unidirectional data flow is what makes react code so predictable and less prone

to errors.

Because of this flow of data that always goes in this one direction.

We can anticipate if something doesn't match, if our views don't match, we know that there's got to

be only one place that's causing these issues to be to come from.

That's why unidirectional data flow and react is so awesome.

Now, I know this might still be confusing because it's so conceptual, but I just want you to keep

this in mind before we start building out our applications.

It all makes sense, I promise.

Now let's get started on actually building out our e-commerce platform.