Now that we implemented this first example,
this first demo, I wanna introduce another new concept,
which is not related to the Dom,
but which is important in JavaScript, in general,
which is a bit more advanced,
and which therefore fits perfectly
into this section, as well.
And this concept is about Variables
and a variation of those variables, called Constants.
Now, we did learn about variables, already,
in the last core section,
and we saw plenty of examples for variables in action.
Just in case you forgot it,
Variables are these labeled data containers,
which we use to store data,
so that we can then use one and the same data
in different parts of our code,
possibly all the multiple times.
Now, variables are called variables
because we can change the values stored in a variable.
We can overwrite the value stored in a variable
with a new one.
If I created a variable with the "let" keyword,
then I can override the value stored in that variable
with a brand new value, if I want to.
And therefore, thus far in this course,
where we only learned about these kinds of variables,
we only worked with such true variables,
which could really change.
Now, often in development, though,
you also deal with so-called Constant values.
So, values which you store in a variable once,
but which you then never change.
So variables where the value actually never changes
are called Constants.
And therefore the name "variable" is a bit strange
because they're not really variable,
but variable is a general term in programming
describing these data containers,
and therefore in JavaScript,
we also call constants variables.
Now constants are created with the "const" keyword,
and up to this point, we haven't seen them yet.
We haven't worked with them yet,
and that's going to change
and therefore I'll now show you
why we might wanna use constants in certain scenarios,
and how we use them.
Now what's the the idea behind constants?
First of all,
it's an alternative to using the let keyword
and to create a variable that can be changed.
But the idea is simple.
Sometimes you have variables,
data containers, that contain a value
which you actually never replace with a new value.
So you might have some entered username,
which you fetched from some input field,
and maybe that never changes once you fetched it.
So once the foreign was submitted, maybe.
In that case,
you can store it in a variable,
but you can also mark it as a const,
with that const keyword,
to make it very clear to you, and to other developers,
that this variable will actually never hold any other value
than the one that was initially assigned,
and if you would try to assign another value,
as you're seeing it here
in this little demo snippet I prepared,
then you would get an error
if this code would be executed,
because you would be violating your own rules,
or your own rule,
which says that this variable, username,
must not be overwritten with a new value.
And that can add extra code safety,
and ensure that the code is not changed
in a way that breaks your program.
That might not matter too much in small demos,
or small projects,
but in bigger projects and bigger scripts,
where maybe multiple developers
are working on the same code,
this can add extra safety,
which avoids unwanted errors.
And, because of that,
it is typically considered a good practice, as a developer,
to be explicit in cases where you can be explicit
about your intentions of your code.
And if you know that some variable
will never hold any other value than the initial value,
whilst you can keep it as a variable,
it is a good idea to turn it into a constant, instead,
to make that very clear,
that this variable will never receive a new value.
And we can apply this to this demo project
we worked on, thus far.
If we have a look at our demo code here,
there is indeed one thing you maybe recognize or see.
And that's the fact that
all the variables I am creating here never change.
None of these variables change.
I create two variables here,
and I assigned values initially,
and then I never assigned a new value thereafter.
And the same is true for all other variables,
and therefore we can.
And that's important, we can,
we don't have to,
but we can turn them all into constants
by replacing let with const.
And the advantage we get from that
is that we make it clear
that these values should never change.
So that's what we can do.
And I did mention at the beginning of this course section,
that, as a developer,
we sometimes wanna be very strict
and we want to ensure that our code
is not getting used incorrectly,
either by us or by other developers.
And here, I actually have a good example for this,
why it might be a good idea
to use a couple of constants here.
Take these element variables,
or constants now, up there,
Actually, these variables, as they were before,
should never receive new values,
because our other code relies on the fact
that in this productNameInputElement
we have that input element, as a value,
because we wanna add an event listener to that,
and because we, for example, wanna extract
the max length from that.
So if we would leave that as a variable,
we, theoretically, could write code
where we overwrite the value stored in this variable
with a different value,
maybe with a different HTML element,
and all of a sudden our other code
that depends on this being the initial value,
the productNameInput field would break.
And of course that is kind of a made up scenario here
because this is a very short and simple script.
And we are the only developer working on this.
But as you get more experienced,
and as you start building more complex websites,
it will not be unusual that you have longer scripts
and that you maybe work on them in a team.
And if you then start overriding some variable,
that one of your colleagues needs, with a different value,
because you think it doesn't matter, for example,
all of a sudden, some other code breaks.
That's why it's optional here in the end,
because this is simple,
but why it, generally, is considered a good practice
to use constants, if you can be that explicit,
and if you never plan on changing that value,
because then you can lock that in
and ensure that it never changes.
But when I do that,
there are a couple of parts in that code
that could be confusing.
For example, I'm creating constants here in this function,
but, wait a second.
Can't this function execute more than once?
It executes for every key stroke,
so technically these variables do change
with every keystroke, right?
Well, not really.
This function executes with every keystroke,
that is correct,
but once it's done executing,
all the variables that were created during the execution,
and that are stored in memory,
because that is where the variables are stored,
they are stored in your computer memory.
All those variables are thrown away,
not what you see on the page
and not any changes that were maybe made by your function,
but the variables which are stored in memory
are thrown away and deleted once this execution finishes.
That means that when the function executes the next time,
for another keystroke, brand new variables are created.
Yes, they have the same name as before,
but they occupy new parts of your computer memory,
because the old ones were deleted.
So, technically, we don't change existing variables,
we always create new ones,
and, therefore,
during the function execution they are constant,
because thereafter they are deleted,
they are never overwritten.
Now, another confusing thing could be
that we do change some of the elements
that are stored in constants.
But for example, on remainingCharsElement,
which is this constant here,
I am changing the text content.
Or on productNameInputElement,
I am adding an event listener.
So, clearly, I am changing
the objects stored in these constants.
And that is correct,
I am changing these objects.
I am changing these Dom elements for example,
but I'm still not changing
the constants, the data containers.
It is super important to understand that,
the value stored in a constant,
in this case here, is the entire HTML element object.
In this case, the object representing the input.
Now, I would only change the constant itself
if I reassign a value with an equal sign,
not to some property of the object,
but to the constant itself.
So if I would reach out to my remaining CharsElement,
and I tried assigning a new value like this,
then I would try to change the constant.
If I instead change the value of some property in there,
then the constant stays the same.
It's just the object stored in the constant
where some of its properties change.
The object itself is the same as before,
just some of its properties changed,
but the object stored in the constant,
and therefore the value of the constant itself,
overall was not overwritten.
And that can definitely be confusing,
but it's essentially just important to keep in mind
that values inside of an object
are just that, values in an object,
not the values stored directly in a constant.
The value stored in a constant is just the object.
And as long as we don't override that
with a brand new object,
and we try to assign a new value to that constant
with the equal character again,
as long as we don't do that,
the constant didn't change.
If that's still a bit confusing,
it is something that will become clearer with more practice,
and the deeper you dive into JavaScript.
Here, we are still only scratching the surface,
we are still only getting started with it.
Nonetheless, I wanted to touch on this concept
and I wanted to bring back constants,
because it is quite common
to use as many constants as possible to make it very clear
whether some variable in your code
will eventually be overwritten with a new value,
or whether it is constant and thus never change.