Now when dealing with events,
the browser actually automatically
provides you with a certain parameter,
which had passes into the function,
you tell the browser to execute when that event occurs.
So in this function,
which we plan on connecting to an event,
we can accept a special parameter,
which will be passed in automatically
by the browser for every event.
So no matter to which event you might be listening to.
And that's an object describing the event that occurs.
So here I'll name this parameter "event".
The name is up to you because it's still your function.
But since I will use this function
for listening to an event,
the browser will provide me a value for this parameter.
I can still name the parameter however I want,
because when the browser executes that function
behind the scenes once the event occurs,
it will just set this first parameter
to this event object value,
no matter how the parameter was named.
And we can now have a look into this event object,
maybe by just console logging it here.
So that we see what's inside of this
automatically generated object.
If I saved that, and I now type a T in here,
I get this event object being locked here.
And if we expanded,
we see we have a couple of properties in there.
Now this is now not an HTML element object,
instead it's an automatically generated object
that contains a bunch of properties
describing the event that occurred.
It actually also contains a couple of methods,
which we don't see here and which we don't need right now.
Now, what we can see
in here are a couple of strange sounding properties,
which are a bit more advanced.
But, we for example, also see this data property,
which conveniently actually contains
data that belongs to this event,
and which event carries which data,
and if it carries any data at all
does depend on which event you are listening to.
So no matter which event you are listening to,
you will always get an event object automatically,
but the content of that object
will depend on the kind of event.
And for an input event, you, for example,
get this data property that carries the
input value the user provided.
Another very useful property we got in there,
is this target property.
That holds the HTML element object
on which this event occurred.
So in this case, the input element.
And this is the exact same element
as we stored here in this variable.
So which we selected with query selector input,
that's the exact same element object,
which we also get access through,
through this target property
on this event object which we get automatically.
And since that's the case,
we got two alternatives for retrieving that value.
We can still use that variable
because we will still need to get access to
this variable anyways,
because we needed to add the event listener.
But inside of this function,
which is executed because of an event,
we actually also could alternatively
get access to our entered text here,
by instead using "event.target",
which is also our input element, as I showed you, ".value".
So this is our input element and
therefore it still has this value property.
And hence, if I do that and I temporarily
comment out this event console log,
then you will still see that with every keystroke,
the current input is being output here on the right.
Now, one very important word about this data property,
which I also show you.
If I do actually
use "event.data" for getting the input,
you will see that there is an important difference.
Event target value or input element value,
always gave us the full value that is currently
stored in this input element.
So the complete word or sentence.
With event data, instead, as you see, as I type here,
I just get to the concrete character
or the concrete input that was inserted
with that last input event emission.
And that therefore is a different behavior,
which sometimes might be what you're looking for.
But very often it's not what you're looking for.
So here, this is different.
It's doing a different thing.
These two approaches on the other hand are equivalents here,
and I'll use event target value,
but we could also use input element value.
As a side note, if we do use event target value,
we have the extra small benefit that we now did get rid
of that external variable,
which we previously used in this function.
Now we're not using it anymore
because now we're extracting the data
we're interested in from that event target.
And that's simply an alternative,
and it is useful to know that we get this
default event object for every event we can
listen to with useful information about the event.
And it's always important to keep in mind
that the concrete information will depend on the event.
For example, for a click event,
if we also accept the event object there,
on that change paragraph text event handler function,
and I console log that event here.
We see that for this click event,
we get different kinds of data.
If I now click on this,
I see I get a mouse event here.
Before you may remembered
this was called an input event.
That's just some internal type description
of this type of event.
And we see that in here, we got our pieces of information,
for example, the coordinates on that screen,
where that click occurred,
and whether the control key was also pressed
in conjunction with the click or the alt key and so on.
So a bunch of extra pieces of information,
that can also be nice to know,
but for example, we also get the target again,
if we would want to interact with
that concrete target again.
These are events and definitely as always with everything,
feel free to play around with that, add more elements,
add more event listeners, log these event objects,
and see what's in there in what you can do with them.
We now gathered all the important information we need
to build a first version of this demo project
I kept showing to you over and over again,
and therefore, that is what we'll do in the next lecture.