So now up to this point in this section,
we made sure that clicking these Edit buttons here
opens this modal.
Now, in case you skipped all the previous lectures
because you just wanted to dive into these new concepts
which are also covered here,
you're welcome to use the attachment
you find on this lecture
to get this same project snapshot as you see it here for me,
and then you should also be able
to click these Edit buttons here and get this overlay
by default without any value in the input though.
Now we wanna make sure that when we enter something here,
and we then click Confirm,
we don't have that default browser mechanism
of trying to send HTTP request to some server,
which is the default.
But instead, I wanna prevent that default
and handle that submission with JavaScript,
read that value with JavaScript,
and then use that value to set the player names here.
And doing all of that is far easier than it might sound.
The first thing we have to do
is get access to our form element that we have here
because it's this form that will be submitted.
Now, we can select this by id,
we can select it by HTML element.
And since I only selected by id up to this point,
and I also wanna practice
the other variance of selecting elements,
I will actually now select these differently here.
I'll add a new constant here in app.js,
which is where I gather
all these elements we have on the page
so that we can use them in the other JavaScript files
because I'm splitting my code
across multiple JavaScript files here for readability.
And in app.js, I will now get my form element
by using document.querySelector
and then I'll select the first form element
which I find on this page,
which in this application, in this website,
is the only form element I have.
So that's the element to which we now store a reference
in this formElement constant.
And now just as we added click listeners
on our elements before,
we can now also use this formElement
and add an event listener on that,
but now it won't be a click listener.
And that's, by the way, important.
I add a listener on the overall form.
I'm not adding a listener on the Submit button.
We could also do that and make it work
by listening to this button,
but the thing that technically happens
when that Submit button is pressed
is that the form is submitted,
and I'm fine with that happening.
It's just this submit event
which I now wanna capture with JavaScript
and handle in JavaScript.
And for this here,
I actually add an event listener to the form itself,
and it's the submit event which is a built-in event
in the browser available in JavaScript
to which I wanna add a listener.
And then in config.js, which is the JavaScript file
that holds all my logic related to player configuration,
I'll add a new function that should be executed
if that submit event is fired,
which I'll name savePlayerConfig
like that.
And it's now this function which I wanna use in app.js.
So as a second-parameter value,
I'll point at savePlayerConfig.
Now, this function here will be executed
when the form is submitted.
And now the interesting thing
will be what we do in this function,
and there are all kinds of things I wanna do.
I wanna get the entered value.
I wanna briefly validate it
and check that it's a valid value.
But most importantly, for a start,
I wanna prevent the default behavior of the browser
because, keep in mind, the default behavior
is that if I click Confirm,
the browser tries to send a HTTP request to a server,
in this case to our development server
which is serving this page,
and the browser tries to send the data there.
That's why this page reloads
because the development server gets this request
and just returns the page
because it doesn't know anything else to do.
Now we'll talk about handling form data on the server
later in the course
when we dive into writing custom backend code.
At the moment, we don't know how to do that.
And this is a browser-based game anyways.
Hence, I wanna prevent that default behavior
and ensure that the browser does not try to send a request
to some server, which doesn't exist here,
and instead handle that with just JavaScript.
And preventing that default is possible
with help of that event object which we get automatically
in functions that are executed because of an event.
And savePlayerConfig will be executed because of an event
because we bind it here with addEventListener.
Then you'll learn we get an event object
that describes the event automatically.
And this event object happens to have
a preventDefault method which we can execute.
You can always console.log that event
to see what's inside of it,
inside of that automatically generated event object.
And I can tell you that one thing that's inside of it
is this preventDefault method.
And this method does what the name implies.
It prevents the browser default behavior
of sending a request automatically.
It avoids that this happens.
And that's important because that allows us
to handle that form submission in JavaScript.
Without that, the request would be sent,
and that would cause a page reload.
Now, whenever the page reloads,
the entire page is executed again,
and hence the JavaScript code is executed again.
So our old running game is simply finished,
and the page is reloaded.
So we can't handle the submission with JavaScript
if we reload the page.
Therefore, we need to prevent the default.
And with that in the next steps,
we can then get the entered data
and then continue with that.
So if I now save this
with just this line of code added in savePlayerConfig,
if you reload, click Edit and click Confirm,
you'll notice that now nothing happens,
which is good because that means the page doesn't reload.
And therefore, now as a next step,
we can see how we can extract data from that form
and then also validate that data and so on.
Now we prevent the default when submitting the form,
and hence we no longer reload the page.
Now as a next step, let's make sure we actually also extract
the value that was submitted here.
And for this, we got another new feature
which we haven't seen before
which makes handling form submission
with browser-side JavaScript extremely simple.
We can add a formData constant,
and this constant should hold an object.
Now, up to this point, we learned that we can create objects
by using these curly braces, and this is true.
But there also is another way
of building objects in JavaScript
at which we'll also have a closer look later in the course
which involves a special keyword, the new keyword,
and then the execution of a function, so to say,
in this case a built-in function which is made available
directly in JavaScript in the browser,
and that's the FormData function.
This here, what we're doing here with new FormData,
is called instantiating an object
based on an object blueprint.
A FormData basically is a function that knows
how to generate objects that have a certain shape.
We can use such blueprints
by executing these blueprint functions as functions
and adding the new keyword in front of them.
Now, we'll learn how to write our own blueprints
later in the course once we need that,
but this is how we can use this built-in blueprint.
And FormData is a built-in blueprint
that actually takes a form,
so a pointer at a form HTML element,
and will then automatically extract
values entered into inputs in that form for us.
So for this, we can pass event.target as a value to FormData
because, as you learned before in this course,
this event object, which describes the event that occurred,
has a target property that points at the HTML element
that was responsible for this event.
And that's the form here
because it's the form that was submitted,
and we are listening to the submit event on that form here.
And by passing a pointer at this form element to FormData,
JavaScript behind the scenes will analyze this form here,
and it will automatically look for inputs in there.
However, not just any inputs,
instead, inputs that have a name field
and also not just input elements like this.
We could also have a dropdown with select
just as you learned in the forms section of this course.
Here it is input element, though,
but, very important, it has a name attribute,
and therefore it will be picked up by FormData
if we pass that overall form to FormData.
And then we can get access to the value
that was identified by FormData
with help of the value we've defined here
on this name attribute.
So that is an identifier by which we will be able
to get access to the entered input value.
And therefore, here in savePlayerConfig,
we can get the enteredPlayername by using formData
and now not the dot notation but a special method
that's available on this formData object.
And that's why this is a blueprint
so that it has the logic for parsing that form
and so that it has a couple of built-in methods,
in this case the get method.
get allows us to get a value of one of our inputs.
And here we pass a string with the identifier
of the input element of which we wanna get the value.
And these are the values provided for the name attributes
that we can enter there.
So in this case playername is the value
provided to the name attribute,
so playername is what we pass as a string to get.
And this will give us
the value entered into the input with that name,
and that's then our enteredPlayername,
so I stored this in a separate constant.
And I'm using a constant
because I don't plan on overwriting
the value stored in here.
Instead, I'll extract it once and keep it stored in here,
hence using a constant is great.
And with that, we now got hold of what the user entered.
And to see that that worked,
for the moment, I'll just console.log enteredPlayername,
save everything and open the Developer Tools here.
And with that,
if I now click Edit and enter Max here and click Confirm,
I see Max here in my Console.
We're not closing the modal yet,
and we're not doing anything with that value yet,
but I can see it here.
So extracting that value works,
and that was the other new concept
that I wanted to introduce here:
how we can use these object blueprints like FormData
and why we're using this here.
Now, this new concept can, of course, be confusing
since thus far, we haven't really used these blueprints.
And you might wonder how do you know which blueprints
for which kind of objects are available,
and why do we not simply build this object on our own?
Well, we don't build it on our own
because we could do that,
but we then have to write the logic for parsing the form,
which is stored in event.target,
and for extracting all the data on our own,
and that's what FormData does for us.
Now, regarding the question
which object blueprints are available in the browser,
you can use sources like MDN
to get an overview of all the available capabilities
that are built into the browser.
If you have a look at the Web APIs page here,
you basically find a list of all the core features
that you can use in JavaScript in the browser.
But whilst this list here looks quite long,
I will say that a lot of the features here are experimental
and not really supported by most browsers,
or only parts of these features are supported,
some features are not to be used anymore,
and not all these features are made available
as object blueprints that you create with the new keyword.
Instead, for example, you also find
the DOM functionality here,
which we, of course, already used a lot
with the document object
with the built-in document variable
that we can use anywhere in our code.
So such things are included here as well,
and you definitely should not learn
a list like this by heart,
but instead, you can use it as a reference
to look up things.
But throughout this course and in general,
as a web developer, as you work on more and more projects,
you will see the common and most important web capabilities
and functionalities that you can use,
and you'll see important object blueprints like FormData
which we did use in this course section.
So as everything in programming,
this is all the question of experience
which you simply gain by building things
and by, of course, advancing with this course
because we'll also see more examples
and functionalities there.