Afrikaans
Akan
Albanian
Amharic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
French
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranî)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
Tutor: So now we learned about State.
And State as you can probably tell by now
is a key concept in React.
Now, there are a couple of things
I wanna clarify about useState
and about why we use a const here, for example.
Now, first let's start with one important thing,
which I did mention in the last lecture already.
UseState registers some State,
so some value as a State
for the component in which it is being called.
And I wanna be even more precise here.
It registers it for a specific component instance.
For example, ExpenseItem here
is being used four times, right?
And Expenses.js we have four ExpenseItems.
Now, every item receives its own separate State
which is detached from the other States.
which is detached from the other States.
We have one ExpenseItem definition here,
but then this function is basically called four times
when we create four ExpenseItems.
when we create four ExpenseItems.
And every time it's called, a new separate State is created
of course in the same way
but managed independently by React.
but managed independently by React.
So if we change the title
in the first ExpenseItem
the other ones are not affected
because they have their own State.
That's really important.
It's on a per component instance basis.
It's on a per component instance basis.
So we have separate States,
even if we create a component more than once.
even if we create a component more than once.
And that's of course crucial
because it would be a rather undesired behavior
if we change something in one item
and all the other items are updated as well.
So that's a good thing to have.
Now, in addition, whenever State changes
because we click a button in this case
it's only this component function
and only that specific instance
where this component is being used
where React will re-evaluate it.
where React will re-evaluate it.
And you can tell that this is the fact
if you add a number of console.log here
in the component, function itself,
in the component, function itself,
where you say ExpenseItem evaluated by React.
This will be called whenever the ExpenseItem
component function is being executed.
component function is being executed.
And therefore if I reload, we see it's called four times
And therefore if I reload, we see it's called four times
which makes a lot of sense
because we're using ExpenseItem four times in expenses.
because we're using ExpenseItem four times in expenses.
So four separate instances
of this component are being created.
But if I now click on change title
in one of the ExpenseItems,
we see it's only printed once.
Which is basically happening
because of what I just explained.
Only that specific instance is being updated
and therefore for being re-evaluated,
and therefore for being re-evaluated,
and the other instances are not affected
by that State change.
And that's important to keep in mind
that State really is separated
on a per component instance basis.
Now there's one other thing which could be confusing.
And that's the fact that I'm using const here.
Why am I using const here
when we do eventually assign a new value?
Well, keep in mind
that we're not assigning a value with the equal sign.
That would indeed fail
but that is not how we assign a new value
when we update a State.
when we update a State.
Instead we call this State updating function,
and the concrete value is simply managed somewhere else
by React.
By calling useState we tell React
that it should manage some value for us.
We never see that variable itself.
So therefore, we just call a function
So therefore, we just call a function
and we never assign a new value to title
with the equal operator.
with the equal operator.
And therefore, using a const is absolutely fine.
How do we get the latest title value then though?
Well, keep in mind that the component function
is re-executed when the State is updated.
is re-executed when the State is updated.
And therefore, of course, this line of code,
line nine, also is executed again
whenever the component function is executed again.
So if we called setTitle
and we assign a new title,
that leads to this component being called again
that leads to this component being called again
and therefore, this new title, this updated title
is fetched from React, which manages the State for us.
is fetched from React, which manages the State for us.
Basically we go to React
and say, "Hey please give me that latest title State
which I told you to manage for me."
And React provides us this latest State in this array
which useState always returns.
which useState always returns.
So we always get a brand new snapshot
of that State when this component function re-executes.
That's how this works under the hood.
Now you might be wondering if that doesn't mean
that we always overwrite any State changes
with props.title again, here.
with props.title again, here.
And here, the special thing is that React keeps track
of when we call useState in a given component instance
for the first time.
And when we call it for the first time ever,
it'll take that argument as an initial value.
it'll take that argument as an initial value.
But if a component is then re-executed
because of such a State change, for example,
React will not reinitialize the State.
Instead, it will detect that this State had been initialized
in the past, and it will just grab the latest State
which is based on some State update, for example,
and give us that State instead.
and give us that State instead.
So this initial value is really only considered
when this component function is being executed
for the first time, for a given component instance.
And I know that this is a lot of knowledge about State
and it might be confusing to a certain extent.
and it might be confusing to a certain extent.
It is just important
to understand how State works under the hood,
because if you're don't fully understand that
then you will run into problems
in more complex React applications
in more complex React applications
where suddenly some value isn't updated
as you expected it to be.
That's why I'm explaining this in great detail.
In a nutshell, using State is simple though.
In a nutshell, using State is simple though.
You just register State with useState,
you always get back two values;
you always get back two values;
the value itself and the updating function.
You call the updating function
whenever the State should change,
whenever the State should change,
and you use that first element
whenever you wanna use the State value,
like here for outputting it in the JSX code.
And React, will do the rest
and it will re-execute the component function
and re-evaluate the JSX code therefore;
whenever the State changes.
That's State and that's an important concept
because it's State which adds reactivity to our application.
Without State, our user interface would never change.
Without State, our user interface would never change.
But with State and with listening to events,
we can make sure that we can react to user input
and that such input can result
in a visible change on our screen.
So State is a super important concept
and of course being able to listen to user events
is also important as you can tell.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.