Theory
A page that just sits there
FestConnect looks great now, but nothing happens. Hovering an event card does not highlight it. Typing an email gives no instant feedback. Pressing Register reloads the page and loses everything.
To react to the user, JavaScript listens for events: signals the browser fires when someone clicks, hovers, types, or submits. You attach a handler (a function) to an event, and the browser calls it at the right moment. The events group neatly into three families.
Theory
Doorbells wired to actions
Think of events as doorbells around your page. One rings when the mouse enters a card (mouseover), one when a key is released in a box (keyup), one when a field is left (blur), one when the form is sent (submit). Your job is to wire each bell you care about to an action. Bells you do not wire simply ring into the void, which is fine.
Theory
The three families
Attach a handler with element.addEventListener('type', handler) (or an inline onclick="...").
- Mouse:
click,mouseover(enter),mouseout(leave),mousemove,mousedown,mouseup. - Keyboard:
keydown(pressed),keyup(released). - Form:
focus(field entered),blur(field left),change(value changed and committed),submit(form sent).
submit fires on the <form> itself, and is usually paired with preventDefault() to stop the page reloading.
At a glance
When each fires
| Event | Fires when | Common use |
|---|---|---|
| click | element is clicked | buttons |
| mouseover / mouseout | pointer enters / leaves | hover highlight |
| keyup | a key is released | live search |
| blur | a field loses focus | validate that field |
| submit | the form is sent | validate + stop reload |
Practical
FestConnect reacts
<div id="card">Robotics</div>
<input id="email" type="email">
<form id="reg"> ... <button>Register</button> </form>
<script>
const card = document.getElementById("card");
// hover: highlight on enter, clear on leave
card.addEventListener("mouseover", () => card.style.background = "gold");
card.addEventListener("mouseout", () => card.style.background = "");
// validate a field the moment the user leaves it
const email = document.getElementById("email");
email.addEventListener("blur", () => {
if (email.value.indexOf("@") === -1) console.log("Email needs an @");
});
// submit fires on the FORM; stop the reload so JS can check first
document.getElementById("reg").addEventListener("submit", (e) => {
e.preventDefault();
console.log("validating before sending...");
});
</script>This example runs in Gri-Learn on the web, where you can edit it and see the output.
Think first
Which event validates a field?
You want to tell a user their email is missing an @ as soon as they finish that field and move on, not on every keystroke. Which form event fits, and why not use keyup?
Show the answer
Use blur: it fires once, when the field loses focus (the user tabs or clicks away), which is exactly 'they finished this field'. keyup fires on every key release, so it would nag mid-typing ('a@' is incomplete but flagged). blur checks at the natural pause. For the final gate you also check everything again on submit. keyup is better for live features like search-as-you-type.
Quiz
Pressing Register reloads the page and wipes the form before your JavaScript can check it. What is the standard fix inside the submit handler?
- Call e.preventDefault() to stop the browser's default form submission
- Use mouseover instead of submit
- Remove the <form> tag entirely
- Add more console.log statements
Show the answer
Call e.preventDefault() to stop the browser's default form submission
A form's default action is to send and reload the page; calling e.preventDefault() in the submit handler stops that, letting your JavaScript validate first and submit only if all is well (A). mouseover (B) is unrelated to submitting. Removing the form (C) loses grouping and the submit event itself. Logging (D) does not stop the reload. preventDefault is the key to client-side validation, which you build fully in Unit 5.
Watch out
Event traps
1. 'mouseremove' is not a real event. The move event is mousemove; leaving an element is mouseout (or mouseleave). Do not memorise a typo.
2. submit is on the form, not the button. Listen on the <form>, and call preventDefault() there.
3. keydown vs keyup: keydown fires as the key goes down (repeats if held), keyup once on release. For reading the final typed value, keyup is usually safer.
Theory
Events call functions, which are next
Every handler here is a function the browser calls for you. Unit 5 formalises functions (parameters, return, calling) and then builds the real FestConnect register() that a submit event triggers, runs full validation, and either redirects or shows an error. Events are the trigger; functions are the action; together they are interactivity.
Summary
Key takeaways
- An event is a user action the browser fires; attach a handler with addEventListener('type', fn) or inline onclick.
- Mouse: click, mouseover (enter), mouseout (leave), mousemove, mouseup.
- Keyboard: keydown (pressed), keyup (released).
- Form: focus (enter), blur (leave, good for validating a field), change (committed), submit (form sent).
- submit fires on the <form>; call e.preventDefault() to stop the reload and validate first. 'mousemove', not 'mouseremove'.
- Memory hook: doorbells wired to actions.