3b Flashcards
(730 cards)
1
Q
38.
A
E
2
Q
What was our third point on becoming a good React developer?
A
What changes when state changes.
3
Q
What does a good React developer do?
A
Decides what changes when state changes.
4
Q
Why don’t we add state to SearchBox?
const SearchBox = ({ placeholder, handleChange }) => {
< input
className="search"
type="search"
placeholder={placeholder}
onChange={handleChange}
/ >
}
It looks like what we’re doing is adding the onChange, giving it a function and this function goes up a level and letting our App.js know that there was an event. But SearchBox, shouldn’t that have these search field state?
Why wouldn’t we put state here?
Why don’t we change the state in SearchBox and instead we trigger whenever an event happens to handleChange up in App.js?
A
because our other component CardList needs to have that information.
5
Q
How did we set up filteredMonsters?
A
By using the search field state to filter based on the user input
6
Q
Show how you can think about the way the app is set up?
A
App.js
/ \
CardList SearchBox
7
Q
It the app was set up like this, why would it be bad was only on SearchBox?
App.js
/ \ CardList SearchBox
A
There’s no way for the CardList component to find out about it.
8
Q
Why couldn’t the CardList component find out about state if state was set up in SearchBox and the app was set up like this?
App.js
/ \ CardList SearchBox
A
Because of one way data flow data can only flow one way. So there’s no way for the search field state to move up and down to the CardList component.
9
Q
Where do we want to put state?
App.js
/ \ CardList SearchBox
A
In a place where it gives us access to whatever needs it. In this case in App.js.
10
Q
What is it called when you place state in a component that gives it access to whatever needs it
A
Lifting state up.
11
Q
How do we architect things in React?
A
COPY FIRST
When an event happens on a component, let’s say a user clicks or types something (in SearchBox for example), well that event triggers the React event system and says, hey something has happened, create an event handler like handle input or handle change and it’s going to go up and let the component that has that state know that hey something has happened you need to update state, and how far up that goes, let’s say we had a component underneath SearchBox, we notify the component that has the state as far up as we need to in order to pass down that information to the components that need that information.
12
Q
q
A
q
13
Q
q
A
q
14
Q
q
A
q
15
Q
q
A
q
16
Q
q
A
q
17
Q
q
A
q
18
Q
q
A
q
19
Q
q
A
q
20
Q
q
A
q
21
Q
q
A
q
22
Q
q
A
COPY FIRST
But I want you to pay attention that you want to decide as a React developer what changes what events that the users take, how far up it goes to let the state know and you want to move the state in a high enough position so that we are still able to pass down that information to different nodes.
23
Q
q
A
q
24
Q
q
A
q
25
q
q
26
q
q
27
q
q
28
If we had let's say a state in number 3
3
/ \
4 5
that the only people that care about it is nodes 4 and 5, where would you put state?
There's no point bringing up the state all the way up to the top node. You want to place the state at node 3 because all these components don't really care about any of this.
29
39.
C
30
What is a fundamental thing in not only JavaScript but also in React.
Writing our own methods on our class components.
31
What are we doing at the moment?
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={e => this.setState({ searchField: e.target.value })}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
We pass in an anonymous function (e) into our SearchBox's handleChange
32
Why do we pass in an anonymous function (e) into our SearchBox's handleChange?
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={e => this.setState({ searchField: e.target.value })}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
In order to set our state.
33
What is this representing in this code?
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={e => this.setState({ searchField: e.target.value })}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
Well this is a special keyword in JavaScript that references the context in which it's being invoked.
34
What does this mean?
Well this is a special keyword in JavaScript that references the context in which it's being invoked.
Well when I say this.state we know that I'm trying to reference the state on our component, our class component.
The only reason that JavaScript is able to say oh when we're calling this.state I want the state object on our component is because the this keyword is set to the context of our class component.
Now the weird thing is that in JavaScript when we write our own class methods we'll see that the this keyword actually gets bound differently depending on how we write the class method.
Now we've already seen class methods in our app component when we look at say the componentDidMount which is a lifecycle method as well as the render.
Inside of these methods they take this format where it's the function name (e.g. render) the brackets (e.g. ()) and then the squiggly brackets (e.g. {}) but the this keyword is bound.
The reason that this is actually happening where the this context is getting bound inside of these methods is because when we call super we're actually extending the functionality that exists on Component (class App extends Component) (which we get from React) that has these lifecycle methods and render. Because we didn't write them, were borrowing them from Component.
When we borrow them from Component, Component actually sets the context of 'this' inside of them for us to our class component. If we were to write our own method for example to represent this method (e => this.setState({ searchField: e.target.value })) that we're passing in we would have to be careful about how we write it.
Now let me show you now the reason in the first place we even want to rewrite this method (e => this.setState({ searchField: e.target.value })) in its own class method is because there's a chance that we might want to use it more than one place and we don't want to write code more than once. We just want to put it in one place pass it in and then change it in one place if we have to, and not have to change it in multiple places.
Now how we would do this is we would write this handleChange method here (above render()). Taking the same format that we see and it would take some event. Which is the synthetic event we're getting back from our input as you remember (this.setState({ searchField: e.target.value })) and then we call this.setState in it.
handleChange(e) {
this.setState({ searchField: e.target.value })
}
And now we're able to actually pass handleChange into our handleChange property on our SearchBox.
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
Now we can write it like this because we're passing the whole callback through to it. e is being referenced in the function definition.
handleChange(e) {
this.setState({ searchField: e.target.value })
}
So we even though earlier we were explicitly writing it out like this.
handleChange={e => this.handleChange}
This is the same equivalent thing as
handleChange={this.handleChange}
because this.handleChange is referencing this full function with the e signature.
handleChange(e) {
this.setState({ searchField: e.target.value })
}
But if we were to save this we'll actually see that our original conversation which is about 'this' context is undefined. If we start typing.
We'll see that we get an error. It says that cannot read properties setState of undefined and it seems that 'this' is undefined.
35
When we write this.state what are we trying to do?
Trying to reference the state on our component, our class component.
36
Why is JavaScript able to say oh when we're calling this.state I want the state object on our component?
Because the 'this' keyword is set to the context of our class component.
37
What is the weird thing in JavaScript when we write our own class methods?
We'll see that the 'this' keyword actually gets bound differently depending on how we write the class method.
38
Where have wee seen class methods in our App component?
componentDidMount which is a lifecycle method as well as the render.
39
Inside of render and componentDidMount methods what format do they take?
The function name (e.g. render) the brackets (e.g. ()) and then the squiggly brackets (e.g. {}) but the this keyword is bound.
40
What is the reason where the 'this' context is getting bound inside of the render and componentDidMount methods?
Because when we call super we're actually extending the functionality that exists on Component (class App extends Component) (which we get from React) that has these lifecycle methods and render. Because we didn't write them, were borrowing them from Component.
41
What happens when we borrow render and componentDidMount from Component?
Component actually sets the context of 'this' inside of them for us to our class component. If we were to write our own method for example to represent this method (e => this.setState({ searchField: e.target.value })) that we're passing in we would have to be careful about how we write it.
42
Why would we want to rewrite this method
(e => this.setState({ searchField: e.target.value }))
in its own class method?
Because there's a chance that we might want to use it more than one place and we don't want to write code more than once. We just want to put it in one place pass it in and then change it in one place if we have to, and not have to change it in multiple places.
43
How would we rewtie this method
(e => this.setState({ searchField: e.target.value }))
in its own class method so we can reuse it?
Write a handleChange method (above render()). Taking the same format that we see and it would take some event, which is the synthetic event we're getting back from our input as you remember (this.setState({ searchField: e.target.value })) and then we call this.setState in it.
44
Show how would we rewtie this method
(e => this.setState({ searchField: e.target.value }))
in its own class method so we can reuse it?
handleChange(e) {
this.setState({ searchField: e.target.value })
}
45
Pass handleChange into our handleChange property on our SearchBox.
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={e => this.setState({ searchField: e.target.value })}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
46
Why do we write it like this?
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
COPY FIRST
We're passing the whole callback through to it. e is being referenced in the function definition.
handleChange(e) {
this.setState({ searchField: e.target.value })
}
So we even though earlier we were explicitly writing it out like this.
handleChange={e => this.handleChange}
This is the same equivalent thing as
handleChange={this.handleChange}
because this.handleChange is referencing this full function with the e signature.
handleChange(e) {
this.setState({ searchField: e.target.value })
}
47
q
q
48
q
q
49
q
q
50
q
q
51
But if we were to save this code what would we see?
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
'this' context is undefined. If we start typing.
We'll see that we get an error. It says that cannot read properties setState of undefined and it seems that 'this' is undefined.
52
Why when we run this code do we see an error?
handleChange(e) {
this.setState({ searchField: e.target.value })
}
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
Well this is actually has to do with the way the functions behave in JavaScript. when we put handleChange
handleChange(e) {
this.setState({ searchField: e.target.value })
}
on our App all it knows is that if we say this.handleChange inside the context of our app, it points to this function
handleChange(e) {
this.setState({ searchField: e.target.value })
}
but it doesn't actually set the context of 'this'.
53
Why isn't the context of 'this' set in this code?
handleChange(e) {
this.setState({ searchField: e.target.value })
}
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
JavaScript, by default, doesn't set its scope of 'this' on functions.
54
How do you make JavaScript set the scope of 'this' in this code?
handleChange(e) {
this.setState({ searchField: e.target.value })
}
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
You have to actually explicitly state what context you want 'this' to be. For us, we want 'this' to be our App component and the method in which we can do it is to define it in our constructor.
55
Show how you would explicitly state what context you want 'this' to be in this code.
handleChange(e) {
this.setState({ searchField: e.target.value })
}
```
render() {
const { monsters, searchFiled } = this.state;
return (
< div className="app">
< SearchBox
placeholder="Text",
handleChange={this.handleChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
}
```
constructor() {
super();
this.setState = {
monsters: [],
searchField: ''
};
}
56
You have to actually explicitly state what context you want 'this' to be. For us, we want 'this' to be our App component and the method in which we can do it is to define it in our constructor. Turn this into a question
Because our constructor is the code that runs first, before anything gets called.
57
What do we want to do with the 'this' keyword in any methods we write?
Make sure that the context of 'this' is correct in all of our methods before any code gets written.
58
How could we...... finish this question
this.handleChange = this.handle Change.bind(this);
59
What is .bind?
A method on any function that returns a new function where the context of 'this' is set to whatever we passed to it. The context of 'this' that we're setting in handleChange
handleChange(e) {
this.setState({ searchField: e.target.value })
}
is the 'this' keyword that is defined inside of our constructor
this.handleChange = this.handle Change.bind(this);
which knows that it's our Component.
60
What is the problem with writing this?
this.handleChange = this.handle Change.bind(this);
It's a very verbose way of writing code.
61
Why is this a verbose way of writing code?
this.handleChange = this.handle Change.bind(this);
Because that means that for every new class method that we write
handleChange(e) {
this.setState({ searchField: e.target.value })
}
we have to bind it.
62
What can we do instead of writing
this.handleChange = this.handle Change.bind(this);
every time we write a new class method?
We can actually leverage ES6 arrow functions and a unique characteristic about them that allows them to set the context of 'this' in whatever it was that declared it in the first place.
handleChange = (e) => {
this.setState({ searchField: e.target.value })
}
63
How can you use ES6 to set the context of 'this' in whatever it was that declared it in the first place.
Arrow functions automatically allow you to set 'this' when
(e) => {
this.setState({ searchField: e.target.value })
}
is defined.
64
So when our Component is getting run by JavaScript for the first time and it's like oh I got to instantiate this new App class what does it do?
COPY FIRST
It checks inside and it sees that there's this handleChange method
handleChange = (e) => {
this.setState({ searchField: e.target.value })
}
that points to an arrow function.
So then it defines the arrow function based on what code we've given it.
And the moment it sees the 'this' keyword
handleChange = (e) => {
this.setState({ searchField: e.target.value })
}
it's like oh this is an arrow function. I'm going to automatically bind 'this' to the place where this arrow function was defined in the first place and the context of this arrow function is our App component.
65
q
q
66
q
q
67
q
q
68
q
q
69
q
q
70
q
q
71
q
q
72
q
q
73
What's something to note about arrow function.
You actually cannot call .bind on them, they automatically get what's called lexical scoping.
74
What is lexical scoping?
It just means that they bind the 'this' context
handleChange = (e) => {
this.setState({ searchField: e.target.value })
}
to the place where they were defined in the first place.
75
Why is lexical scoping handy for us?
We can actually see this now that it will continue to work as it did before, even though we're not calling the bind in the constructor anymore so this is really handy for us because it saves us that extra step.
76
How could you prove lexical scoping another way?
COPY FIRST
Inside of our browser the tightest/highest level context is our window object.
If I were to define a function called newFunc
const newFunc = () => console.log(this);
and what we're logging is console.log(this).
When we invoke newFunc we'll see that 'this' is that window object. When JavaScript saw us define newFunc to this function and brought it into existence within our JavaScript context so we could start using it, it had to lexically scope 'this'
const newFunc = () => console.log(this);
to the window object because the window object was the context in which our arrow function was given its existence.
77
What is this similar to?
const newFunc = () => console.log(this);
finish question.
COPY FIRST
This is the same case with our handleChange method
handleChange = (e) => {
this.setState({ searchField: e.target.value })
}
When handleChange was declared, which means that when JavaScript first created our App component it also defined all of the methods (render, componentDidMoun, handleChange) on our components including handleChange, and it saw that handleChange was an arrow function and because of this, when this arrow function came into existence to JavaScript, it was going to bind any references to 'this' inside of it, to the context in which it was defined, which is our App component just like we saw with our myFunc in the browser, that's what happened with our handleChange. This is great because if we want to write class methods we just write them with this arrow syntax and now the context of 'this' is what we expected to be without us having to write all of that extensive binding code, if we were to write it the other way so with this in mind it makes it easier for us to write our class components and their methods.
78
q
q
79
q
q
80
q
q
81
q
q
82
q
q
83
q
q
84
q
q
85
q
q
86
q
q
87
q
q
88
q
q
89
q
q
90
q
q
91
q
q
92
q
q
93
q
q
94
q
q
95
40.
E
96
41.
Q
97
What's a good rule of thumb regarding 'this'?
Use arrow functions on any class methods you define and aren't part of React (i.e. render(), componentDidMount()).
98
42.
O
99
43.
O
100
How many ways are there to connect to a Git repository?
Two.
101
What ways are there to connect to a Git repository?
Through HTTPS or SSH.
102
How can you switch between the two options HTTPS and SSH
By clicking the switch https/ssh button after clicking clone.
103
What is something to note about HTTPS?
Doesn't require setup.
104
What is the recommended way to clone according Github official documentation?
Via HTTPS.
105
What is SSH?
A unique fingerprint you generate for your computer in your terminal, which you then let your github account know about so it knows that requests from this computer using SSH (cloning/ pushing/ pulling) are safe to do.
106
44.
D
107
How would you add the title?
Add it as an H1 here at the top of our App.js.
108
How would we get the font?
COPY FIRST
Now this font we can get from Google fonts.
fonts.Google.com
and we can see all these different fonts that Google allows us to use in our project.
So I'm just gonna find the one we want called Bigelow Rules.
Hit this a little plus and Google gives us a link that we can add to our index.html inside of our head.
We just added at the bottom (of the head section) and now we have access to Bigelow Rules in our project.
If we go to App.css I'm going to add a new rule for H1 and I'm going to say font family is Bigelow Rules. I'm also going to set the font size to 72 pixel and the color.
The background we're gonna put into our index.css and this is a file that gets generated by create-react-app.
The reason why they've already added this styling to the body and the code is because create-react-app wants the exact same base styling across all browsers. Different browsers might run different things like a different font or a different margin or padding so create-react-app is just trying to equalize that when the project starts. Inside of this body we're just going to add this linear gradient to our background.
Our projects not live yet but we can actually host this really easily using github pages. create-react-app has made it really easy to use the github pages service and github lets us host static web sites for free.
The first step we've got to do is we have to go to github and then we have to make a new repository.
Name it something.
Then copy the key, use HTTPS if you haven't got SSH setup.
Go to the terminal and then I'm going to do two things.
First I'm going to connect our actual project to that repository.
We've just made by doing
git remote add origin and then the key that was copied.
Next I'm going to actually include the gh pages package by doing
yarn add gh-pages
next I'm gonna go to our package.json file and I'm gonna do two things.
The first thing I'm going to do is I'm going to add (under "private": true;)
"homepage": "https://(githubUserName(without brackets)).github.io/(name of the of the project(without brackets))",
Then add two scripts.
The first one is called ptedeploy and in this predeploy I'm just going to call build because as we remember our build script builds all of our real code into the final code that our browser needs.
"predeploy": "yarn build",
And then I'm gonna call deploy and this one I'm going to say gh-pages/ -d built.
"deploy": "gh-pages/ -d built"
Now this is gonna run predeploy before it runs deploy which is really awesome because npm and yarn both know to run any script that you have pre with before you run the actual script.
So it's gonna run predeploy before it runs deploy and then it's going to serve up up to our github project.
Now we're gonna go back to our terminal and then we're gonna run our new deploy script
yarn deploy
and now we actually see it runs our predeploy script first and then we're gonna see that it actually runs our deploy script right after.
Now this is going to build all of our project files that we need for the final project and then we're going to add
after you run yarn deploy
git add -A
and then we're gonna write a commit message
git commit =m "adding files for github pages"
and now we're going to push this up
git push origin master
so once this is all pushed up to our final project repository we're gonna go back to our github and we're gonna refresh.
Now we should see all our files in here and if we now go to the settings and when we scroll down we want to make sure that the source is actually pointing to github pages branch.
gh-pages branch
If yours is pointing to master just make sure to set it to gh-pages branch.
And now if we go to our link we see our website is live.
It's actually served at this URL and that's awesome because get hub lets us serve these static websites for free very easily and very quickly and you can see how if you wanted to build a quick static web site using react it's really easy to build it and then serve it using create-react-app and giyhub pages.
Now when we actually build our final application which is a very more dynamic e-commerce web site, we're going to actually use databases and we're going to leverage a lot more code and github won't be enough for us to serve.
And I'm going to show you how we're gonna take all of these things that we learned building this application and then expand upon them in that lesson.
109
q
q
110
q
q
111
q
q
112
q
q
113
q
q
114
q
q
115
q
q
116
q
q
117
q
q
118
q
q
119
q
q
120
q
q
121
q
q
122
q
q
123
q
q
124
q
q
125
q
q
126
q
q
127
q
q
128
q
q
129
q
q
130
q
q
131
q
q
132
q
q
133
q
q
134
q
q
135
q
q
136
q
q
137
q
q
138
q
q
139
q
q
140
q
q
141
q
q
142
q
q
143
q
q
144
q
q
145
q
q
146
q
q
147
q
q
148
q
q
149
q
q
150
q
q
151
q
q
152
q
q
153
q
q
154
q
q
155
q
q
156
q
q
157
q
q
158
q
q
159
q
q
160
45.
R
161
q
COPY FIRST
make a new folder called pure-react
mkdir pure-react
Inside of pure react
cd pure-react
make a source folder
mkdir src
and then inside of our source folder
cd src
make an index.html file
touch index.html
and then open it up
code .
Inside of our index.html file, generate our basic HTML.
html:5 (then press return)
Go to in the body, add a div with the I.D. of root.
< div id="root >< div / >
In our index.js file we replace that root div with the actual contents of our application.
And then include the two packages react and react-dom.
Below the the root div write a script tag where the src goes to the react project.
< script src="link" >< script / >
The "link" is something called unpackage which lets us very easily bring in the react library and then we're gonna do the same thing with react-dom and now our react project has both these libraries.
So why are there two? React is kind of just the API, but then the thing that actually renders out to the DOM is what ReactDOM is. Whats there reason for both? React is a great kind of engine, but you could have many different views that run on the same engine. So ReactDOM this for the web and React Native, for example, is for native Android and iOS.
So while it use it the same React engine it uses a different package other than ReactDOM to render its Android and iOS views.
So that's why it's such a great package because you can even find ones like react 360 if you want to build 3D stuff, like virtual reality stuff.
How could you show that it actually removes what's inside of this root div when we actually render in our React code.
Type React not rendered between the root div.
< div id="root >React not rendered< div / >
Open up our index.html in the browser
In the terminal
open index.html
We see that 'React is not rendered' appears in the browser.
Because we haven't actually done that call where we replace the content inside of this div with our application and we haven't built the application yet but first if we open up our dev tools we can actually see now because we pulled in both those packages, in the console we have access to both React and ReactDOM.
type React and ReactDOM into the console
These are the objects that the two packages provide into our global JavaScript namespace, once we brought those packages in
This is pretty much the same thing that we do when we import in react and react-dom into our files. It just gives us access to these two things.
Add my own script tag and start writing some JavaScript
< script >
JavaScript goes here
< script / >
So first I'm going to write a functional component called app and i'm going to return react.createElement.
```
const App = () => {
return React.createElement()
}
```
createElement is a function on React that builds out those elements that we saw when we wrote our return, inside of for example the CardList component.
It just we returned from this function this HTML markup. createElement is actually what it's doing but instead of using JSX this is vanilla.
So what we've got to do is we write in (the argument ) that we want to make a div.
```
const App = () => {
return React.createElement("div")
}
```
You can put any other HTML tag or whatever that you're looking for and then the second argument is an object of any attributes that I want to add to my div.
So if I wanted to add a class or an I.D. I would put them in here.
```
const App = () => {
return React.createElement("div", {class: "card-list"})
}
```
So I can keep it empty.
```
const App = () => {
return React.createElement("div", {},)
}
```
And then the third and last argument is any children we want to nest inside of our div.
```
const App = () => {
return React.createElement("div", {},
React.createElement("h1",
{},
"React is rendered")
);
};
```
And I'm gonna put on an H1, no attributes, and inside of our H1 I'm going to put the text 'React is rendered'.
Right and now we have our functional component and I'm gonna call ReactDOM.render.
```
const App = () => {
return React.createElement(
"div",
{},
React.createElement("h1", {}, "React is rendered")
);
};
```
ReactDOM.render(React.createElement(App), document.getELementById("root"))
NOTE: These last two arguments are completely optional.
That's all we were doing when we rendered out < App / > component, except with JSX but now we're just doing it with vanilla JavaScript.
That's all the react library does for us it just helps us create these HTML elements using functions or classes.
Now let's say I wanted to make a const person write that renders and an array.
```
const Person = () => {
return React.createElement("div", {}, [
```
])
}
So if we want to multiple elements/multiple children inside of this div we would just use an array and inside I would do React.createElement, H1 and empty object and I'm gonna put
"john" and then I'm gonna make another one except it's gonna be a p tag and it's gonna say developer.
```
const Person = () => {
return React.createElement("div", {}, [
React.createElement("h1", {}, "John"),
React.createElement("p", {}, "developer"),
])
}
```
and now instead of just rendering in our application that each one of our actors render right, I'm also going to render in multiple Persons
```
const App = () => {
return React.createElement(
"div",
{},
[
React.createElement("h1", {}, "React is rendered"),
React.createElement(Person),
React.createElement(Person),
React.createElement(Person)
]
);
};
```
I'm going to react create element person and I'm gonna do it three times.
Now if we check our application we'll see, we rendered our person component three times.
Now we hard coded these values, but what if we wanted to do the same thing we did with our other components right. We wanted to use props. Well because it's just a functional component as we had before we can do exactly that can pass props into this.
And instead of "John" do something like props.name right or props.occupation and these are whatever it is that the attributes are that we want for this component to take.
```
const Person = (props) => {
return React.createElement("div", {}, [
React.createElement("h1", {}, props.name),
React.createElement("p", {}, props.occupation),
])
}
```
So now if we wanted to actually add those then we would do our name inside of that second argument with that empty object..
const App = () => {
return React.createElement(
"div",
{},
[
React.createElement("h1", {}, "React is rendered"),
React.createElement(Person, {name: "John", occupation: "Developer"}),
React.createElement(Person, {name: "Jane", occupation: "Developer"}),
React.createElement(Person, {name: "Mark", occupation: "Developer"})
]
);
};
Now if we look at our application we see we can pass in our props right.
That's all we were doing when we were writing our functional components and our class components.
It's just that with JSX we don't have to call React.createElement constantly.
It knows to read from that html markup that we were writing and that's why JSX is so good when we use it with React because what we did is kind of redundant.
It's just a quality of life improvement.
Now you might be wondering how would we do it with are class components. It's actually the exact same.
So instead of an app I'll just make a class app extends react component.
class App extends React.Component {
}
It's a class that exists on react that it exposes to us and then we have access that render and in that render I'm just going to return what it is that we had before
class App extends React.Component {
render() {
return React.createElement(
"div",
{},
[
React.createElement("h1", {}, "React is rendered"),
React.createElement(Person, {name: "John", occupation: "Developer"}),
React.createElement(Person, {name: "Jane", occupation: "Developer"}),
React.createElement(Person, {name: "Mark", occupation: "Developer"})
]
);
};
}
}
and now instead of app being a functional component we're still rendering our class component of app. And if we look we'll see their application stays the same.
React does for us it helps us build out these views and that's why React and ReactDOM are such great libraries because it just helps us simply build out our views and manage figuring out what the right thing in our views is to update.
162
q
q
163
q
q
164
q
q
165
q
q
166
q
q
167
q
q
168
q
q
169
q
q
170
q
q
171
q
q
172
q
q
173
q
q
174
q
q
175
q
q
176
q
q
177
q
q
178
q
q
179
q
q
180
q
q
181
q
q
182
q
q
183
q
q
184
q
q
185
q
q
186
q
q
187
q
q
188
q
q
189
q
q
190
q
q
191
q
q
192
q
q
193
q
q
194
q
q
195
q
q
196
q
q
197
q
q
198
q
q
199
q
q
200
q
q
201
q
q
202
q
q
203
q
q
204
q
q
205
q
q
206
q
q
207
q
q
208
q
q
209
q
q
210
q
q
211
q
q
212
q
q
213
q
q
214
q
q
215
q
q
216
q
q
217
q
q
218
q
q
219
q
q
220
q
q
221
q
q
222
q
q
223
q
q
224
q
q
225
q
q
226
q
q
227
q
q
228
q
q
229
q
q
230
q
q
231
q
q
232
q
q
233
q
q
234
q
q
235
q
q
236
q
q
237
q
q
238
q
q
239
q
q
240
q
q
241
q
q
242
q
q
243
q
q
244
q
q
245
q
q
246
q
q
247
q
q
248
q
q
249
q
q
250
46.
L
251
q
COPY FIRST
how you can update your packages.
So because I'm in the future the version of react that I'm seeing that just got released is different
from the version that we are using throughout this course right now.
The latest version of React is 16.10.2.
In the course though the version of React 16.8.6.
It's a very minor version change but there are a couple of new things that came out in that react version.
So the first thing to do is check what version of whatever packages that you want to upgrade are that you are currently running.
The easiest way to do so is simply using inside of your terminal
yarn list
So if you type in yarn list and then the name of the packages, here I'm checking out react react-dom and react-scripts I will see the version number
yarn list react react-dom react-script
These can be upgraded.
Now instead of directly modifying the value here there is another thing that we can do to make sure that whenever we either want to upgrade we can always use the latest version.
Now the way to do that is simply to go to our package.json inside of our project.
So inside of our package that Jason you'll see that I have inside of these two dependencies for react and react-dom 16.8.6 and 16.8.6 and 3.0.0 for react-scripts. So if you have used create-react-app to create your application as you've been following on this course you may see that there's this little carat symbol ^ in front of your version. All that means is that this is a rule that tells whatever package manager we're using whether it be yarn or NPM when ever it sees NPM upgrade or yarn upgrade to update to the latest stable non breaking version.
So if you see this carat then you see that whenever you installed your package even if it's 16.8.6 it will try and get the latest version.
In my case though because I did not have it whenever I run yarn install or npm install it will find just the exact version which is 16.8.6.
So I'm just going to add this carrot in to all these locations.
And what this will now do is whenever I run yarn upgrade it will try and upgrade with these new rules.
yarn upgrade
The issue that you will encounter if you change your package.json and then try to simply run
yarn upgrade
is that you will see that you have an outdated lock file, it will say please run yarn install and try again. This is perfectly fine.
All this means is that you aren't upgrading is not going to work here because we updated the rules in our package.json when we added that carrot.
Instead we have to run
yarn install
There is a yarn.lock or a package.lock inside of your application folder.
So what is this lock file? All this lock file is it an auto generated file by either NPM or a yarn that locks the version of all the packages inside of our application within a specific range based on the rules that we set inside of package.json.
So the rules being simply what we saw in the package.json file as our version number.
If I use a carrot, it's saying that I want it to be at least 16.8.6 or greater but not breaking. What that means is that when we had it before without this carrot the yarn lock file was generated saying that the version of React and ReactDOM and react scripts are locked to exactly that version.
Now that we've added this carrot it gives more flexibility which means the yarn.lock file is out of date and needs to be updated.
And this lock file only updates whenever you run yarn install.
So why do we need a lock file? The lock file is simply there so that if multiple people are working on this application they are all using versions of these dependencies that don't conflict with each other because maybe somebody is running react 17 someone is running react 16 and there is a difference in features that might be breaking in the application. The yarn.lock file just ensures that everybody is using a consistent version of these dependencies. But with that after we ran your install we generated a new lock file and from now on you can simply run yarn upgrade whenever you want to upgrade these dependencies.
We can just double check to make sure the version of these packages that we got are updated.
So if I run
yarn list react react-dom react scripts
I'll see that they're now at 16.10.2 for react and react-dom as well as 3.2.0 for react-scripts.
So with this I have now updated my packages to the latest version.
Now let's see how we do this and NPM. Here I have a separate repository that is a complete clone of our last repository.
The only difference is that in this one I'm using NPM as my package manager instead of yarn.
All I have to do in order to update these packages is run npm update.
The main difference here is that npm update will force the versions to update to their latest versions.
However it's still good to be explicit in our rules in package.json so that we know what kind of versioning we want to do.
So first let's just check what versions we have actually installed for react react-dom and react-scripts.
npm list
and then we type out the actual package names the same way.
npm list react react-dom react-scripts
so here with this it's just like yarn before we see that our versions are 16.8.6 for react and react-dom and 3.0.0 for react-scripts.
So in order to update this we can go into our package.json and we can add Tilda ^ in front of react, react-dom and react-scripts just to be explicit and then we simply run npm update.
One thing I want to note is that even if you don't add the tilde it will update the version numbers and it will overwrite your package.json file to show the latest version. So npm update and then npm install are both a little different because npm install sometimes will skip over certain versions if it doesn't see that it's a major update.
The safest way to make sure that you actually do update all your versions if you want to is run npm update it takes a little longer.
So here we'll see already that it's told us that it's updated react on to 16.10.2 react scripts the 3.2.0 and react 16.10.2.
You'll also see at the bottom of the terminal that it says found zero vulnerabilities.
So what are our vulnerabilities. You might see this number change sometimes whether you see it as a warning in your github or maybe when you do something with your npm it'll show you that there's certain vulnerabilities.
vulnerabilities are essentially these minor security concerns, sometimes they're major, most of the time they're minor, that has to do with either a dependency that you have installed or a dependency that your packages depend upon that you yourself don't know that you also installed.
So for example react probably has something like 60 other packages that it depends upon. And one of those might have a security concern.
The easiest way to actually fix this inside of npm is to run
npm audit fix
and this command will go through and update the versions to a version of a package where it doesn't have the security concern anymore.
Unfortunately with yarn, this is not so easy.
While yarn does have access to a yarn audit, all it will do is it will audit all of the packages as well as those packages dependency packages to see if there's any vulnerabilities in any of them.
If it does it will list them to you and show you at what severity.
But for you to actually update it there's no such easy command as npm audit fix in yarn.
You'll have to do is manually install and upgrade all of those packages that you see with a vulnerability, if you do use yarn as your main package manager. So that's just one thing to highlight as the main difference between npm and yarn as well as how the commands work.
252
q
q
253
q
q
254
q
q
255
q
q
256
q
q
257
q
q
258
q
q
259
q
q
260
q
q
261
q
q
262
q
q
263
q
q
264
q
q
265
q
q
266
q
q
267
q
q
268
q
q
269
q
q
270
q
q
271
q
q
272
q
q
273
q
q
274
q
q
275
q
q
276
q
q
277
q
q
278
q
q
279
q
q
280
q
q
281
q
q
282
q
q
283
q
q
284
q
q
285
q
q
286
q
q
287
q
q
288
q
q
289
q
q
290
q
q
291
q
q
292
q
q
293
q
q
294
q
q
295
q
q
296
q
q
297
q
q
298
q
q
299
q
q
300
q
q
301
q
q
302
q
q
303
q
q
304
q
q
305
q
q
306
q
q
307
q
q
308
q
q
309
q
q
310
q
q
311
q
q
312
q
q
313
q
q
314
q
q
315
q
q
316
q
q
317
q
q
318
q
q
319
q
q
320
q
q
321
q
q
322
q
q
323
q
q
324
q
q
325
q
q
326
q
q
327
q
q
328
q
q
329
q
q
330
q
q
331
q
q
332
q
q
333
q
q
334
q
q
335
q
q
336
q
q
337
q
q
338
q
q
339
q
q
340
47.
R
341
q
COPY FIRST
Look at the developer tools in Monsters Rolodex and look at our DOM.
The DOM is our representation of our actual application.
Inside of our App component that we built, we have that H1, we have that input and we have this card-list.
These are all elements that are children of this App and inside of our card-list, is those children, the card-containers.
If we were to actually look at this from a very basic representation we'll see that it actually looks like this tree.
App
/ | \
h1 | search-box
card-list
/ | \
card-component-nodes
So this tree actually represents our actual DOM.
However, in order for our actual DOM to update any of the elements, it's actually extremely slow.
So it takes the DOM a lot of energy to update any of these elements.
Now what React does is it copies this actual DOM tree and it makes it in JavaScript just like we see when we write our JSX. Our JSX is also just JavaScript that returns what looks like these HTML elements. What react will do is it'll completely copy this actual DOM except this it will call the virtualDOM and the virtual DOM is just a complete copy of this actual DOM but in JavaScript.
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 React doesn't actually want to rerender the entire DOM it only wants to affect the thing that matters.
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 the name it's gonna change the email according to 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 (changes the colour to red) so it'll actually make the change and then what it will do is it will compare this new virtual DOM to the old DOM and then it will see that two of the values are different
So then it will know, okay, let's actually apply the DOM changes to the element that's different and when it does that it's actually way more performant because it doesn't have to mess around with the DOM unless it knows exactly what elements it needs to update. It's also able to batch multiple DOM updates together efficiently.
And that's why react so fast because of its ability to build out these virtual DOMS and then compare and contrast against the real DOM to see what's changed and then make the appropriate updates to exactly the right node.
Can we actually see this in action. Well we definitely can.
What we've got to do first is we've 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,
this.state = {
monsters: [],
searchFiled: '',
title: ''
}
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 are user typed in so instead of filtering out our monsters what we're gonna do is we're just going to display the monsters.
onSearchChange = (event) => {
this.setState({ searchField: event.target.value, title: event.target.value });
}
```
return (
< div className="App">
< SearchBox
placeholder="Text",
handleChange={this.onSearchChange}
/ >
< CardList monsters={filteredMonsters} />
< / div >
);
```
```
return (
< div className="App">
< SearchBox
placeholder="Text",
handleChange={this.onSearchChange}
/ >
< CardList monsters={Monsters} />
< / div >
);
```
Go to 7.13
We don't want that search feature for now. We're also going to add in this title field 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 our title update.
Now if we enable inside of our additional rules (three dots in chrome development tools > more tools> rendering ) let's just add actually our rendering. What we'll see if we enable paint tools (located in Chrome development tools in Rendering Tab) is that this web site will flash green in all the areas that are getting updated whenever DOM elements are updating it will change it.
So if we refresh we'll see the whole page flashing because it's mounting and rendering everything for the first time.
Now let's say we actually start typing in this the search box when we type this we'll see that only this title is getting updated. Nothing else is getting re rendered because react 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 re rendered. It doesn't touch anything else and that's what is so great about Reacts virtual DOM and it's efficiency when it comes to deciding what in our DOM to re render.
Now let's go back to our application and let's undo this, so we get our app back to the state that it was before.
Now we know that we have our monsters array on the state of our app and we passed that after we've modified it, after we create a new array (in the render section), but based off of this data (in the state) array using our search field to filter out the monsters that don't match (in the return()) and we pass that into the CardList. Then our card-list.component is the one that will then map out using the data that got passed into it, the new cards.
So if we were to look at this again except let's just focus on our application.
App
/ | \
h1 | search-box
card-list
/ | \
card-component-nodes
Right that monsters array sits at our app, ot gets passed in the card-list and then it generates these components.
And these end up being all of our actual components that we view.
(This is actually all of our views(don't know what this means)) what React does when it's actually rendering out the application is that React is based off of this data that we saw. The data from the state of our app component (the monsters array) gets passed to this card-list component which then renders out the card-component-nodes components. If, for example, whenever we type in our search field and we update and change that filtered monsters array, that gets passed into our card list 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 into the actual card-list component instead.
So if we took all this and we moved it into here (card-list.component) so that the data actually sits at the card-list level, well what happens if we were to do that same thing if we were to modify that array at this level right (card-list)
App
/ | \
h1 | search-box
card-list
/ | \
card-component-nodes
instead of it's sitting in the App it's now in the card-list and then we modify that array.
Well these children (card-component-nodes) would still get re rendered. React would re render any part of the tree below this node (card-list) because the data that's used to generate these views(card-component-nodes) actually sits here (card-list) but anything above it (the parent) our App and then the siblings (h1, search-box), the search-box and the title would not re render. React has no reason to render anything above this node (card-list) because the data only affects the children below this node. This concept is called uni directional 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 an quick image of what that looks like.
Views
/| \
/ \|
State
342
q
q
343
q
q
344
q
q
345
q
q
346
q
q
347
q
q
348
q
q
349
q
q
350
q
q
351
q
q
352
q
q
353
q
q
354
q
q
355
q
q
356
q
q
357
q
q
358
q
q
359
q
q
360
q
q
361
q
q
362
q
q
363
q
q
364
q
q
365
q
q
366
q
q
367
q
q
368
q
q
369
q
q
370
q
q
371
q
q
372
q
q
373
q
q
374
q
q
375
q
q
376
q
q
377
q
q
378
q
q
379
q
q
380
q
q
381
q
q
382
q
q
383
q
q
384
q
q
385
q
q
386
q
q
387
q
q
388
q
q
389
q
q
390
q
q
391
q
q
392
q
q
393
q
q
394
q
q
395
q
q
396
q
q
397
q
q
398
q
q
399
q
q
400
q
q
401
q
q
402
q
q
403
q
q
404
q
q
405
q
q
406
q
q
407
q
q
408
q
q
409
q
q
410
q
q
411
q
q
412
q
q
413
q
q
414
q
q
415
q
q
416
q
q
417
q
q
418
q
q
419
q
q
420
q
q
421
q
q
422
q
q
423
q
q
424
q
q
425
q
q
426
q
q
427
q
q
428
q
q
429
q
q
430
q
q
431
48.
A
432
q
COPY FIRST
I've just started a base create-react-app project for us and the only thing I've done up until now is just up there is to convert App from a function to a class component.
Now what I want to do is just simply change the two a tags to buttons, and delete what's in the button.
```
class App extends React.Component {
render() {
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" />
< p >
Edit
< p / >
< button
```
```
>
Update State
< / button >
< / header >
< div / >
);
}
}
```
And then finally we'll create some sort of state that will display in the < p > tags. Let's just say that we want to create again using constructor I'm going to call super, as we always do. Then finally we'll say this state is going to equal and let's just say Meaning of Life is going to be 47. And display the state.
```
class App extends React.Component {
constructor() {
super();
this.state = {
meaningOfLife: 47
}
}
render() {
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" />
< p >
{this.state.meaningOfLife}
< p / >
< button
```
```
>
Update State
< / button >
< / header >
< div / >
);
}
}
```
But we also want to update the state via the button. So we create an onClick we'll say it's going to be this.handleClick and we'll create this method (handleClick) on this component (above render) we'll say handleClick we'll use an arrow function so that we don't have that issue with 'this' keyword and then in here we'll simply say.setState to update our meaning of life. Well let's just incremented by 1.
```
class App extends React.Component {
constructor() {
super();
this.state = {
meaningOfLife: 47
}
}
handleClick = () => {
this.setState({ meaningOfLife: this.state.meaningOfLife + 1 })
}
render() {
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" />
< p >
{this.state.meaningOfLife}
< p / >
< button
onClick={this.handleClick}
>
Update State
< / button >
< / header >
< div / >
);
}
}
```
So if I save this and go back and I click on update state I see that my state is updated every time I click.
Now here's the thing as I've mentioned before the react library helps us manipulate the DOM but to be efficient and to be fast it usually batches multiple setState calls because sometimes we can have in our app multiple setState calls or multiple locations where we change the DOM. Instead of it calling setState every single time it sometimes gets smart and says oh don't worry if there's a lot of setStates happening I'll batch them together and update them all into one single update for performance. Now in our case this worked.
But React actually does not guarantee that when we call this (by clicking on the update state button) and we update state that this (the number) is going to work. Why is that.
Because this call off setState is asynchronous.
handleClick = () => {
this.setState({ meaningOfLife: this.state.meaningOfLife + 1 })
{
What does that mean.
It means that when we click on the button this doesn't happen immediately
this.setState({ meaningOfLife: this.state.meaningOfLife
When we call this.setState we give control to the React library and we say hey you take care of this you know the best time to update the state for me, I don't care just do it for me and I'll keep doing something else. So unlike a synchronous call that this happens immediately
this.setState({ meaningOfLife: this.state.meaningOfLife
when we call it.
Asynchronous just happens sometime in the future. We actually saw this when it the instructor mentioned the fact that if we ever wanted to check the state, let's say after we make this call let's say we do a console.log
handleClick = () => {
this.setState({ meaningOfLife: this.state.meaningOfLife + 1 })
console.log(this.state.meaningOfLife)
{
If we did this we'll notice that this state of meaning of life
handleClick = () => {
this.setState({ meaningOfLife: this.state.(here?)meaningOfLife + 1 })
console.log(this.state.meaningOfLife)
{
won't get updated even though it's called after the setState. If I save and go back and open up the developer tools you'll see here that when I click the button my state is 48 but it console logged 47 and it's always 1 behind and that is because this line runs
this.setState({ meaningOfLife: this.state.meaningOfLife + 1 })
we give control to React to update the state for us but it doesn't do it immediately. It does it asynchronously. By the time we call this line (the console.log) the state hasn't been updated. We saw a way to get around.
We can give a second parameter to our setState call which is our callback and the callback simply takes a function so it can just have a simple arrow function here that console.logs for us.
handleClick = () => {
this.setState({ meaningOfLife: this.state.meaningOfLife + 1 },
() => console.log(this.state.meaningOfLife))
{
I save go back and I click you see that now everything is in sync.
But here's the thing, this is actually that practice. Why is that. Well because our app is simple right now, this is working, however, because of the way setState batches work into a single update like I mentioned, if we had multiple setState calls it doesn't guarantee that when we increment meaningOfLife that this part (meaningOfLife) will be the latest version. Maybe another part of the app modifies meaningOfLife to be something else.
So because there is no guarantee there's a rule and react that we have to follow and the rule is this. If in your setState call you ever use this.state directly like this.
handleClick = () => {
this.setState({ meaningOfLife: THIS.STATE.meaningOfLife + 1 },
() => console.log(this.state.meaningOfLife))
{
So instead of meaningOfLife being something with state e.g. dolphins where we don't use the state that's completely fine and we can just give it an object
handleClick = () => {
this.setState({ meaningOfLife: 'dolphins' },
() => console.log(this.state.meaningOfLife))
{
But if we ever want to use this.state or this.props in our updates to calculate something then we should do something instead of what we do here which is giving it an object.
The important part is the first parameter, this object instead of an object can also be a function and it's a function that receives two things. One is the state or to be more descriptive the previous state and then the second parameter is the previous props. So if I just wrap this in brackets since these are the parameters
handleClick = () => {
this.setState((prevState, prevProps),
() => console.log(this.state.meaningOfLife))
{
and we call this function and in here I do the exact same thing where we return an object You could add the brackets here so that I don't have to just type in return so that we can actually return the object here. If I do this I can say,
MeaningOfLife and say this.state.meaningOfLife + 1.
handleClick = () => {
this.setState((prevState, prevProps) => {
return {meaningOfLife: this.state.meaningOfLife + 1}
},
() => console.log(this.state.meaningOfLife))
{
MeaningOfLife just like this so this whole function
(prevState, prevProps) => {
return {meaningOfLife: this.state.meaningOfLife + 1}
},
is our first parameter and our second parameter is here
() => console.log(this.state.meaningOfLife))
So if I do this I now can use this previous state (prevState) to guarantee that when I update this (meaningOfLife) this is the latest previous state before the update. So this is just best practice that you have to remember. Anytime you want to update state and there's props or state that you need to use within the update, then you should use this syntax of using a function instead of an object.
So in here instead of calling this.state directly I simply just say previous state.
handleClick = () => {
this.setState((prevState, prevProps) => {
return {meaningOfLife: prevState.meaningOfLife + 1}
},
() => console.log(this.state.meaningOfLife))
{
So if I save this and go back and I click update you see that everything is still working properly. Now what about this prevProps. In order for us to play with this we need to have some sort of props or properties on this App component but up until now we've only seen App be the parent or the biggest higher level component. It's the top of the tree. But as I mentioned previously, state can live anywhere. We don't need to have state in just one component. We can bring it down the tree to another node. We can mix and match.
But let me show you how we can get props to the App component.
We simply go to index.js where the App component is and lets say we'll add a increment attribute and this increment attribute will be what we increment by.
ReactDOM.render(< App increment=1 / >, document.getElementById('root'))
Now if I do hear one this is going to give me an error it's going to say well I'm trying to do JSX and I have no idea what this means because remember we need to pass it some sort of a value in JavaScript which means wrapping it in brackets so this evaluates to a JavaScript expression.
ReactDOM.render(< App increment={1} / >, document.getElementById('root'))
If I save this I now have these props now let's say I wanted to use the props, so now I'm going to get the increment prop so I'll just say this.props.increment
handleClick = () => {
this.setState((prevState, prevProps) => {
return {meaningOfLife: prevState.meaningOfLife + this.props.increment}
},
() => console.log(this.state.meaningOfLife))
{
If I save this all right. This is working nicely.
Again if I wanted to just use previous props I can just make sure that it's the latest and nothing has changed it by using previous props.
handleClick = () => {
this.setState((prevState, prevProps) => {
return {meaningOfLife: prevState.meaningOfLife + prevProps.increment}
},
() => console.log(this.state.meaningOfLife))
{
If I save it once again everything is working. Now one last thing.
Usually it's good practice to put in here in the constructor and super to put in the props like this.
```
constructor(props) {
super(props);
this.state = {
meaningOfLife: 47
}
}
```
Now what does this do. This allows you to actually use the props in the constructor.
What do we mean if I do here this.props I can now use this.props inside of the constructor.
```
constructor(props) {
super(props);
this.state = {
meaningOfLife: 47
}
this.props
}
```
So if you ever need to use this.props inside of the constructor you need to pass this here. So for example if I just simply do this.props equals props I save it and I remove the props from here.
```
constructor() {
super();
this.state = {
meaningOfLife: 47
}
this.props = props
}
```
You'll notice that I'll get an error props is not defined because I can't use this.props this way.
Now there are occasions when that needs to happen.
So it's always recommended that you just add props in case you ever need to do this stop props in here.
```
constructor(props) {
super(props);
this.state = {
meaningOfLife: 47
}
this.props = props
}
```
So let's say for example in our state calculation we want to say that meaning of life is going to equal 47 plus this.prop.increment so I'll originally be 48.
```
constructor(props) {
super(props);
this.state = {
meaningOfLife: 47 + this.props.increment
}
}
```
if we save here we have previous props here for the increment
handleClick = () => {
this.setState((prevState, prevProps) => {
return {meaningOfLife: prevState.meaningOfLife + PREVPROPS.INCREMENT}
},
() => console.log(this.state.meaningOfLife))
{
if I go back you see that it's now 48 as the default (in the browser) so that the next update will be forty nine.
So this is why we passed props in the constructor and super. Now the final thing I want to show you is that create-react-app has something called the alternate class syntax.
Now in regular JavaScript you can't do this and there are proposals that are going to allow future versions of JavaScript to do this but you may see them in common react code basis, so I want to show you because some people don't like this constructor having so many lines of code.
Sometimes a state is just a simple thing.
So for example if we didn't have any of this increment and we just had the plus one here let's say no props, well we can just remove all of this like so and just simply say that state is equal meaningOfLife which equals forty seven and that's it.
state = {
meaningOfLife: 47 + this.props.increment
}
handleClick = () => {
this.setState((prevState, prevProps) => {
return {meaningOfLife: prevState.meaningOfLife + 1}
},
() => console.log(this.state.meaningOfLife))
{
If I do this it leaves out the constructor and initializes the state as a class field declaration.
Again this is something because of the create-react-app and the Babel compiler that it has underneath but you are going to see this in some code bases where you just want to set state really easily but you won't have access to the props inside of here as we did with the constructor so that if I save this this should still work and it does. Keep in mind state updates are asynchronous and we want to be careful.
The rule is this.
Do you ever want to manipulate or use the state somehow after the update. Then add in a second parameter which will be a function where you can use that updated state.
() => console.log(this.state.meaningOfLife))
{
Maybe in your update and in your state update you have to use the state as part of that calculation or the props as part of the calculation then you should pass this function form
(prevState, prevProps) => {
return {meaningOfLife: prevState.meaningOfLife + 1}
}
to update the state.
Otherwise you can just use the simple object notation that we've seen up until now. If you get this concept this is going to take you very far in your career.
433
q
q
434
q
q
435
q
q
436
q
q
437
q
q
438
q
q
439
q
q
440
q
q
441
q
q
442
q
q
443
q
q
444
q
q
445
q
q
446
q
q
447
q
q
448
q
q
449
q
q
450
q
q
451
q
q
452
q
q
453
q
q
454
q
q
455
q
q
456
q
q
457
q
q
458
q
q
459
q
q
460
q
q
461
q
q
462
q
q
463
q
q
464
q
q
465
q
q
466
q
q
467
q
q
468
q
q
469
q
q
470
q
q
471
q
q
472
q
q
473
q
q
474
q
q
475
q
q
476
q
q
477
q
q
478
q
q
479
q
q
480
q
q
481
q
q
482
q
q
483
q
q
484
q
q
485
q
q
486
q
q
487
q
q
488
q
q
489
q
q
490
q
q
491
q
q
492
q
q
493
q
q
494
q
q
495
q
q
496
q
q
497
q
q
498
q
q
499
q
q
500
q
q
501
q
q
502
q
q
503
q
q
504
q
q
505
q
q
506
q
q
507
q
q
508
q
q
509
q
q
510
q
q
511
q
q
512
q
q
513
q
q
514
q
q
515
q
q
516
q
q
517
q
q
518
q
q
519
q
q
520
q
q
521
q
q
522
q
q
523
q
q
524
q
q
525
q
q
526
q
q
527
q
q
528
q
q
529
q
q
530
49
COPY FIRST
All lifecycle methods serve different purposes and they all trigger at different times in a components lifecycle.
This project really comprises of a slightly modified version of what the base project that create-react-app gives us and in it I've just modified our app component to have two buttons that decide on what to show for our lifecycle component.
Now I know this lifecycle component just looks like a bit of text right now but I just put it here so that you can see whether or not it's there or not.
And what I mean by that is whenever you click this toggle lifecycle button you'll see that that component disappears.
I'm pulling it off the DOM based on whether or not you've clicked or toggled the lifecycle button.
And then the update text button whenever you click we'll just put this _hello.
And the more you click it the more _hellos get appended to that text.
This is what the code looks like.
import Lifecycles from './lifecycle.component';
```
class App extends React.Component {
constructor() {
super();
```
```
this.state = {
showChild: true,
text: ''
};
}
render() {
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" / >
< button
onClick={() =>
this.setState(state => ({
showChild: !state.showChild
}))
}
>
Update Text
< button / >
{this.state.showChild ? < Lifecycles text={this.state.text} / > : null}
< / header >
< / div >
);
}
}
```
The folder structure it's pretty much just the base create-react-app project.
The only difference is that we have this lifecycle component that import into our app component and then I append it right here (under the button).
The first thing that we need to notice is that our App is a class based component that has a state where the initial values are the showChild property that is a boolean with the default value being true and then this text value which is a string with the default value being an empty string.
If you ignore the div and the header tag and the image tag because these are pretty much just presentational HTML elements.
The main thing is to look at is these two buttons and then of course this code right here below the button. In the first button we have this onClick that will fire off our function that calls setState where we set the showChild property of our state equal to the opposite value of what it was currently. We do that by using this bang operator. And what this bang operator does is it evaluates any boolean or any value to the opposite value that it is. So for example if showChild is true then I want to set the state value of showChild to the opposite value meaning that it will be bang true which is equal to false. bang just says give me the opposite boolean value of whatever that value is.
So if state.show Child is false then bang false is equal to true.
It's a really handy way for us to toggle between a true and false state by simply calling this bang operator.
So whenever you click it it will set the showChild value to the opposite value as the next state value.
In the second button we have this onClick that fires an anonymous function that will call setState that sets the state.text to whatever it currently is except adding on this extra '_hello' string.
So all we do is whenever we click it our state text just gets more and more '_hello' strings appended to the end of it.
Finally we have this code here
{this.state.showChild ? < Lifecycles text={this.state.text} / > : null}
that determines whether or not to hide or show our life cycles component. So this you might see is kind of odd looking. This is actually what's called a ternary operator and it sounds like a weird thing but it's actually just shorthand that allows us to write easier if else statements. All it is is it takes the form of a question mark and a colon with different things between it. You can see it as three parts.
The first part is what we want to evaluate as true or false. Well if you can imagine that we had some if statement.
if () {
} else {
}
The first initial if statement right where we evaluate something about whether or not it's true or false is pretty much what this is saying in the first part of the ternary operator. That's why we use this boolean value that we have in our state as true or false. So I'm saying if this.state.showChild it is true then I want to either render this (the lifecycle component) or this (null). So this first thing that we see after the question mark
< Lifecycles text={this.state.text} / >
is what gets evaluated if showChild, (so whatever's on the first part ( this.state.showChild )) is true. So if showChild is true render the Lifecycles component.
If this.state.showChild is false then render null. So you can see this last section here pretty much being what goes into the else statement. so you can see this as what goes here (finish 7.03). This as what goes here and this as what goes here so it's pretty much just a really handy and quality of life coding a syntax that allows us to write if l statements in a much easier and readable way.
531
q
q
532
q
q
533
q
q
534
q
q
535
q
q
536
q
q
537
q
q
538
q
q
539
q
q
540
q
q
541
q
q
542
q
q
543
q
q
544
q
q
545
q
q
546
q
q
547
q
q
548
q
q
549
q
q
550
q
q
551
q
q
552
q
q
553
q
q
554
q
q
555
q
q
556
q
q
557
q
q
558
q
q
559
q
q
560
q
q
561
q
q
562
q
q
563
q
q
564
q
q
565
q
q
566
q
q
567
q
q
568
q
q
569
q
q
570
q
q
571
q
q
572
q
q
573
q
q
574
q
q
575
q
q
576
q
q
577
q
q
578
q
q
579
q
q
580
q
q
581
q
q
582
q
q
583
q
q
584
q
q
585
q
q
586
q
q
587
q
q
588
q
q
589
q
q
590
q
q
591
q
q
592
q
q
593
q
q
594
q
q
595
q
q
596
q
q
597
q
q
598
q
q
599
q
q
600
q
q
601
q
q
602
q
q
603
q
q
604
q
q
605
q
q
606
q
q
607
q
q
608
q
q
609
q
q
610
q
q
611
q
q
612
q
q
613
q
q
614
q
q
615
q
q
616
q
q
617
q
q
618
q
q
619
q
q
620
q
q
621
q
q
622
q
q
623
q
q
624
q
q
625
q
q
626
q
q
627
q
q
628
q
q
629
q
q
630
50.
COPY FIRST
class Lifecycles extends React.Component {
constructor() {
super();
console.log('constructor!');
}
componentDidMount() {
console.log('componentDidMount!');
}
componentDidUpdate() {
console.log('componentDidUpdate!');
}
componentWillUnmount() {
console.log('componentWillUnmount!');
}
shouldComponentUpdate(nextProps, nextState) {
console.log('shouldComponentUpdate!', nextProps);
return true
}
render() {
console.log('render!');
return (
< div className="lifecycls" >
< h3 > LifecycleComponent < / h3 >
{this.props.text}
< / div >
);
}
}
Look at this life cycles component, called Lifecycles.
It's just a component called Lifecycles which is a class component extending the React component. So inside of here are the possible lifecycle methods that we want to look at and inside of each one I'm just logging the name of the lifecycle that it is so that when it gets called and we look in our console we'll see the order in which they're getting fired.
Now before we take a look into what these life cycles are there's actually a diagram we can look at on the React web site and on this diagram it will show us in this graph form when each method fires depending on what phase the component is in.
search 'react lifecycle method diagram'
So the first phase we gonna look at is the mounting phase. The mounting phase is the phase when the component is being put on the DOM for the first time. So when it's mounting when it's in the mounting phase it starts before our component is actually on our DOM, before it's on our page. When it starts mounting it first looks at the component, so for us our Lifecycles component and then it sees the constructor and it calls the constructor first.
So inside of our constructor we have our super, and the super is pretty much just a method on all classes inside of their constructors that say if I'm extending from some other class component I want to pull in all of their methods and all of their functionality. This might sound complicated but all you need to know is that what that does is it allows our class component to have access to these lifecycle components. Because you can see it as if these lifecycle components and when they get called in the order of all this functionality is actually originally bound to this React component, this React class component that we need to borrow from.
So we're essentially saying extend me all of that functionality into my class component called Lifecycles, so the constructor when we call super, it's like okay this is when I want you to give me all that functionality, so that I can bind it all to my class component. Inside of the constructor as well is when we can declare our state. So when we call this.state we do it inside of our constructor specifically for this reason because this is when our state becomes initialized on our class.
```
class Lifecycles extends React.Component {
constructor() {
super();
console.log('constructor!');
```
this.state = {
}
}
So the constructor gets called first for this reason so that our components other lifecycle methods if they need to use the state are aware of the state because it's initialized inside of our constructor.
After the constructor call it then calls our render method and the render method is when our component tells JavaScript, okay, this is what I want you to display in terms HTML. This is also where any prop values get evaluated in the HTML
```
render() {
console.log('render!');
return (
< div className="lifecycls" >
< h3 > LifecycleComponent < / h3 >
{this.props.text}
< / div >
);
}
```
So because we're passing in that text string this is when JavaScript like oh I'm calling the render method on this class, I'm also going to evaluate the value of this prop.text and then turn it into something that I can display in the HTML and that's how we're able to see that string value that would get passed in as a prop or anything for that matter. This evaluation is happening inside of our render call.
After the render comes when React actually updates the DOM, or it makes updates to our component. The main thing here is where Reacts like okay now that I know what the component looks like because of the render and I know what state and whatever things are on the class component because the constructor I'm now going to put it on the page, I'm going to mount it.
And then once it mounts the componentDidMount lifecycle method gets fired and inside of here
componentDidMount() {
console.log('componentDidMount!');
}
is where it's like okay, the component has mounted, its in its base state, it's properly evaluated then I'm gonna call my lifecycle method componentDidMount and if we look at our application (in the console) we'll see that that's the order that it happens. We get the constructor first, then the render gets called and then our componentDidMount gets called.
And usually this is where after we've loaded our base bare class component inside of a componentDidMount is where we start to do things like our API calls.
If you remember from our earlier instance where we made an API call to get all the users for our Monster's Rolodex and the reason for this is because we want to load the base component first before we start fetching data and updating our component so that it looks different from the base state, because we don't know how long that API call might take, latency might be slow your connection might be poor, but this is the order and how we should leverage this lifecycle method is that we wait for the base component to mount and then we're like okay let's use our componentDidMount method to update it into its next state.
And this next state this updating phase is the next phase of our component after the base mounted state is on our DOM. The next phase is the updating phase.
631
q
q
632
q
q
633
q
q
634
q
q
635
q
q
636
q
q
637
q
q
638
q
q
639
q
q
640
q
q
641
q
q
642
q
q
643
q
q
644
q
q
645
q
q
646
q
q
647
q
q
648
q
q
649
q
q
650
q
q
651
q
q
652
q
q
653
q
q
654
q
q
655
q
q
656
q
q
657
q
q
658
q
q
659
q
q
660
q
q
661
q
q
662
q
q
663
q
q
664
q
q
665
q
q
666
q
q
667
q
q
668
q
q
669
q
q
670
q
q
671
q
q
672
q
q
673
q
q
674
q
q
675
q
q
676
q
q
677
q
q
678
q
q
679
q
q
680
q
q
681
q
q
682
q
q
683
q
q
684
q
q
685
q
q
686
q
q
687
q
q
688
q
q
689
q
q
690
q
q
691
q
q
692
q
q
693
q
q
694
q
q
695
q
q
696
q
q
697
q
q
698
q
q
699
q
q
700
q
q
701
q
q
702
q
q
703
q
q
704
q
q
705
q
q
706
q
q
707
q
q
708
q
q
709
q
q
710
q
q
711
q
q
712
q
q
713
q
q
714
q
q
715
q
q
716
q
q
717
q
q
718
q
q
719
q
q
720
q
q
721
q
q
722
q
q
723
q
q
724
q
q
725
q
q
726
q
q
727
q
q
728
q
q
729
q
q
730
51
COPY FIRST
After our component has been mounted onto the DOM any future updates either to the props, the state or us manually forcing an update on our component will cause our component to go into the updating phase.
So what is the updating phase and what triggers updates.
import Lifecycles from './lifecycle.component';
```
class App extends React.Component {
constructor() {
super();
```
```
this.state = {
showChild: true,
text: ''
};
}
render() {
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" / >
< button
onClick={() =>
this.setState(state => ({
showChild: !state.showChild
}))
}
>
Toggle Lifecycles
< / button >
< button
onClick={() =>
this.setState(state => ({
text: state.text + '_hello'
}))
}
>
Update Text
< / button >
{this.state.showChild ? < Lifecycles text={this.state.text} / > : null}
< / header >
< / div >
);
}
}
```
Well if for example inside of our App.js we're passing in the text value off of this.state,
text={this.state.text}
into our lifecycle method
< Lifecycles text={this.state.text} / >
which for us is this string
this.state = {
showChild: true,
text: ''
};
where whenever we click the button
```
< button
onClick={() =>
this.setState(state => ({
text: state.text + '_hello'
}))
}
>
Update Text
< / button >
```
we just append _hello to that string, we just make it longer and longer which we can see in the browser.
Every time we update and click the 'Update State' button and update our state
and this new state value
{this.state.text}
gets passed into our lifecycle component.
< Lifecycles text={this.state.text} / >
our lifecycle component goes into the updating phase and it's like oh I got new props I should probably re render my component, not remount though. Our component is already mounted. It doesn't need to go through mounting again.
It doesn't need to be destroyed because React doesn't want to create new elements for it. Doing that is actually very costly on the browser but selectively changing pieces of the HTML inside of our component is way easier because all it needs to change is this.props.text
class Lifecycles extends React.Component {
constructor() {
super();
console.log('constructor!');
}
componentDidMount() {
console.log('componentDidMount!');
}
componentDidUpdate() {
console.log('componentDidUpdate!');
}
componentWillUnmount() {
console.log('componentWillUnmount!');
}
shouldComponentUpdate(nextProps, nextState) {
console.log('shouldComponentUpdate!', nextProps);
return true
}
render() {
console.log('render!');
return (
< div className="lifecycls" >
< h3 > LifecycleComponent < / h3 >
{this.props.text}
< / div >
);
}
}
it doesn't need to change the h3 it doesn't need to change the div so React's like oh okay I'm just going to update
this.props.text, or I'm also going to run through those lifecycle methods that might be affected in this updating phase because the props have changed and maybe these lifecycle methods do use the props to do something. That's all up to us and how we want to write our code.
The props have changed. I'm going to start going through my update cycle. The update cycle could also be triggered if this.setState gets called inside of our component so we don't actually call setState inside of our Lifecycles class because we don't have state, which is fine but if we look at our App component we do have state and we do call setsState whenever we click either of the buttons.
So whenever we click one of the buttons React re-renders this component as well
```
class App extends React.Component {
constructor() {
super();
```
```
this.state = {
showChild: true,
text: ''
};
}
render() {
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" / >
< button
onClick={() =>
this.setState(state => ({
showChild: !state.showChild
}))
}
>
Toggle Lifecycles
< / button >
< button
onClick={() =>
this.setState(state => ({
text: state.text + '_hello'
}))
}
>
Update Text
< / button >
{this.state.showChild ? < Lifecycles text={this.state.text} / > : null}
< / header >
< / div >
);
}
}
```
it goes through the update phase of our App component as well because there might be things inside of our component that depends on the state to determine what they need to do including our render.
If for example we were displaying this.state.text inside of our component ourselves, the component needs to decide okay I should probably re render because there's a chance that this component is rendering something on the state. So that's why it does it.
It's like okay the components state has changed as well, let's also run through our update phase for our component. Finally we can also force an update by calling this.forceUpdate inside of our component anywhere.
render() {
this.forceUpdate()
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" / >
< button
onClick={() =>
this.setState(state => ({
showChild: !state.showChild
}))
}
This forces the component to update everything. This should be avoided because it's bad practice. It just forces to go through the update phase but inside of the update phase it just goes through these following methods.
Show Slide 3:45
So just like our mount, It also goes to the render again because new props comes in or new state comes in, React has to go through its process of deciding oh what in my components changed and then it's going to update the DOM, so it's going to update the DOM with the changes that are required in that component.
Again we're not re mounting the component we're just making the change to the piece of the component where it's affected. Then it calls componentDidUpdate similar to componentDidMount.
It's the lifecycle method that gets called after the updates have been made to the DOM and here we can see this when we click Update text and go to the concole in the browser. We see it calls render and then it calls our componentDidUpdate.
One thing I want is to look at is actually this lifecycle method (shouldComponentUpdate).
class Lifecycles extends React.Component {
constructor() {
super();
console.log('constructor!');
}
componentDidMount() {
console.log('componentDidMount!');
}
componentDidUpdate() {
console.log('componentDidUpdate!');
}
componentWillUnmount() {
console.log('componentWillUnmount!');
}
shouldComponentUpdate(nextProps, nextState) {
console.log('shouldComponentUpdate!', nextProps);
return true
}
render() {
console.log('render!');
return (
< div className="lifecycls" >
< h3 > LifecycleComponent < / h3 >
{this.props.text}
< / div >
);
}
}
shouldComponentUpdate is a lifecycle method that determines whether or not this whole chain needs to happen.
And it actually exists between these things that would trigger this updating phase that happen (new props, new state or forceUpdate) and the following lifecycle methods to get triggered. shouldComponentUpdate actually sits right here (between new props, new state or forceUpdate and render). What it does is it gets the props and then the next state. When props change they come in as a parameter or when state changes it also comes in as a parameter. What happens is that based on the new props that are coming in or the new state after we've called setState we can determine whether or not we want to go through these other lifecycle methods including actually re rendering our component.
Because if we don't want to render a component we don't have to.
And how we would do this is actually if we looked at our App.js
```
class App extends React.Component {
constructor() {
super();
```
```
this.state = {
showChild: true,
text: ''
};
}
render() {
return (
< div className="App" >
< header className="App-header" >
< img src={logo} className="App-logo" alt="logo" / >
< button
onClick={() =>
this.setState(state => ({
showChild: !state.showChild
}))
}
>
Toggle Lifecycles
< / button >
< button
onClick={() =>
this.setState(state => ({
text: state.text + '_hello'
}))
}
>
Update Text
< / button >
{this.state.showChild ? < Lifecycles text={this.state.text} / > : null}
< / header >
< / div >
);
}
}
```
so for example whenever setState gets called we know that what happenes is our render call it gets called in our component.
So whenever we call setState we're actually re rendering this whole App.js component which actually ends up re rendering the Lifecycles component
< Lifecycles text={this.state.text} / >
even if we were not passing 'text' in. This component,
because it's a child of our App.js gets re rendered. I can actually show you if I get rid of this prop
< Lifecycles / >
so we're no longer passing the prop into our Lifecycles method. Even though I click the 'Update Text' button in the browser you will see, in the console, that our render method and then componentDidUpdate is getting called from our Lifecycles component. This is because of how Reacts node tree works. React knows that inside of this component (< Lifecycles /> component) any of the children might need to be re rendered because it's just going to assume that everything in the render is affected possibly by the state changing or new props coming into this component (App.js?).
So whenever a component gets updated, re rendered all the children also get re rendered and this happens whenever, again as we saw, props change or setState gets called or force update gets called inside of the component.
Now the reason this is important is because let's say we called setState on a property that our lifecycle method doesn't care about let's say for example we had a another state property.
```
this.state = {
showChild: true,
text: '',
message: ''
};
```
For example message. And then the message value we used somewhere else inside of the component. We don't pass it into Lifecycles as a prop we just use it somewhere else.
Well if setState gets called the updates its message we just saw that it's going to force our component (< Lifecycles / > component?) to update and our component if the state.text hasn't changed
< Lifecycles text={this.state.text} / >
why do we need to re render our Lifecycles component.
That's a waste of processing power. It's a it's slowing down our browser.
So what we could do here is use shouldComponentUpdate(). It allows us to selectively hijack and not go through that re render. We don't have to re render our component. Here we can see we do that by what gets returned as a boolean value from shouldComponentUpdate.
shouldComponentUpdate(nextProps, nextState) {
console.log('shouldComponentUpdate!', nextProps);
return true
}
If we return true then our component will update. It will go through the cycles and it will run through that componentDidUpdate and here we actually see us logging the next props that we're getting.
```
constructor!
render!
componentDidMount!
shouldComponentUpdate!
{ text : "_hello" }
render!
componentDidMount!
shouldComponentUpdate!
{ text : "_hello_hello" }
```
So whenever we click 'Update Text' we see that the text is coming through. That's the property, the new text property that we're getting.
But if we return false
shouldComponentUpdate(nextProps, nextState) {
console.log('shouldComponentUpdate!', nextProps);
return false
}
what happens is that it doesn't even go through any of those lifecycle methods except for shouldComponentUpdate because when we return false we're saying I don't want my components to re render. And the reason we would do this is for example if we were to check the nextProps that we're getting. If we see that the string value for our text has not changed
class Lifecycles extends React.Component {
constructor() {
super();
console.log('constructor!');
}
componentDidMount() {
console.log('componentDidMount!');
}
componentDidUpdate() {
console.log('componentDidUpdate!');
}
componentWillUnmount() {
console.log('componentWillUnmount!');
}
shouldComponentUpdate(nextProps, nextState) {
console.log('shouldComponentUpdate!', nextProps);
return true
}
render() {
console.log('render!');
return (
< div className="lifecycls" >
< h3 > LifecycleComponent < / h3 >
{this.props.text}
< / div >
);
}
}
then we don't care to update them. We don't need to. There's no reason for us to do that.
And here we will see that if we click Update text we're getting this call, our shouldComponentUpdate.
```
constructor!
render!
componentDidMount!
shouldComponentUpdate!
{ text : "_hello" }
shouldComponentUpdate!
{ text : "_hello_hello" }
```
But because we're returning false it does not go through the next cycle methods that need to happen inside of our updating phase.
And the reason we would do this as I mentioned is because maybe we don't want to re render because our text didn't change and we can actually force this to happen if inside of our button click instead of appending hello
```
< button
onClick={() =>
this.setState(state => ({
text: state.text + '_hello'
}))
}
>
Update Text
< / button >
```
we just keep the text as what it is.
```
< button
onClick={() =>
this.setState(state => ({
text: state.text
}))
}
>
Update Text
< / button >
```
But because we're calling setState we're forcing the state to change and because we're forcing the state to change we're forcing React to re render our component.
So now inside of our lifecycle methods what we can do is here we can actually say we want to return instead of false, we want to return if next props.text does not equal this.props.text.
shouldComponentUpdate(nextProps, nextState) {
console.log('shouldComponentUpdate!', nextProps);
return nextProps.text != this.props.text
}
So if the current text is the same as the next prompts text then don't re render because there's no point to. We don't need to re render our component because our props have not changed.
So now we'll see if we click up a text it doesn't update
```
constructor!
render!
componentDidMount!
shouldComponentUpdate!
{ text : "" }
shouldComponentUpdate!
{ text : "" }
```
but if we go back and we say that, okay, now the text is changing,
```
< button
onClick={() =>
this.setState(state => ({
text: state.text
}))
}
>
Update Text
< / button >
```
```
< button
onClick={() =>
this.setState(state => ({
text: state.text + '_hello'
}))
}
>
Update Text
< / button >
```
well then our component will update accordingly.
```
constructor!
render!
componentDidMount!
shouldComponentUpdate!
{ text : "_hello" }
render!
componentDidUpdate!
shouldComponentUpdate!
{ text : "_hello_hello" }
```
So this is mainly just for performance. If the properties coming in are not different than the props that we already have then there's no reason to re render. Now understanding this update phase is so fundamental to us becoming better React developers because much of how code is structured and how the architecture
for React is written, is based around this update phase. THe update phase is fundamentally what the React library does for us. This is why we write components, this is why we break our code up the way it does because this update phase is how React makes our lives easier for us whenever it updates the DOM based on new properties coming in based on us calling setState or forcing updates inside of our components.
This triggers a chain reaction of, for example, our App component updating also its children, not only rendering itself but re rendering any child components it has.
And then those child components also update. But that's the thing, if we trigger big updates like this there may not be a need to even update these components if as we saw the props do not actually change. If the props don't change nothing about this component (shouldComponentUpdate?)needs to update. So leveraging the lifecycle methods will allow us to possibly improve the performance of our application but also give us a better idea of when we should do what with our components.
