The Vuecation Continues

• Vuejs makes it easy to add event handling to button clicks etc.
  • Easy because it is hiding a lot of what is going on
• This week, the native browser event API
  • low level, like assembly language (6.1903/4)
  • more powerful/flexible
  • better performance
  • harder to use
• Provides broader understanding for future work

Functions as function arguments?!

• In JS, functions are objects too
• They can be variable values, function arguments, return values etc
• They can even have properties, just like any other object
• Deep 🐇 hole. We will learn more about it after spring break

			let handler = function (evt) {
				evt.target.textContent = "Clicked";
			};
			clickme.addEventListener("click", handler);
		

Let's think about this

• Goal: tell your code what code to run when an event happens
• Could provide a code string the browser reads/executes when the event happens
  • But if the string has syntax errors, you don't find out until the event is triggered and code string is read
• Instead, define a function that is your code
  • browser can understand and check it and report errors when your script loads
  • Other benefits we'll discuss later
• Important: browser understands your function when script loads, but doesn't run it until the event is triggered.

Arrow functions

• Less cluttered shorthand for defining functions.
• Some minor differences discussed later.

			let handler1 = function (evt) {
				evt.target.textContent = "Clicked";
			}; //two equivalent definitions
			let handler2 = evt => evt.target.textContent = "Clicked";
		

A shorter way to declare functions. There are a few differences from function declarations, that we will explore later in the semester.

Events beyond UI interaction

• Resource: error, load, unload, …
• Network: online, offline
• Window: message, close
• Loading/Parsing: load, DOMContentLoaded, unload, …

Removing events

			let handler = evt => evt.target.textContent = "😊";
			button.addEventListener("click", handler);
			button.removeEventListener("click", handler);
		

Presentation &rarr CSS

• Move presentatoin out of JS to CSS
• Think of presentation as a (reactive) function of state of system
• CSS is great for expressing that dependency
• Reactive, so easier to think about and debug
• Taking presentation out of JS means less complicated JS
• If you need to change your JS to change something purely presentational, that's a sign your presentation is in the wrong place
• Similar benefits to moving presentation to Vuejs templates instead of JS

If a tree falls in a forest and no one is around to hear it, does it make a sound?

Events occur whether we listen to them or not

Event bubbling Events start off at a target, and propagate up the DOM tree

Different targets

• event.target: (smallest/deepest) element where event occurred
• event.currentTarget element where the event handler is running now (because you attached it there)

Not all events bubble

Bubbling is just another heuristic!

• focus (but focusin does!)
• blur (but focusout does!)
• mouseenter (but mouseover does!)
• mouseleave (but mouseout does!)
• load
• error

			element.addEventListener(eventName, evt => {
				if (evt.bubbles) {
					evt.stopPropagation();
				}
			})
		

Stopping Propagation

• event handler can call event.stopPropagation()
• event bubbling stops
• prevents containing elements from hearing event
• useful if you have e.g. a clickable element (button) inside a clickable element (detailselement)

Event capturing Events start off at document and propagate down to target

				element.addEventListener(
					eventName,
					callback,
					{capture: true}
				)
			

Bubbling or Capturing?

• Two different models---which should we use?
  • Netscape Navigator used bubbling, Microsoft Internet Explorer used capturing
  • Different orders of execution
  • Different powers to stop propagation
• After the browser wars, truce: do both!
  • Events bubble, then capture
  • But default event handlers are during bubble

What happens when you press ⌘+S
(or Ctrl + S) in a web page?

What happens when you press ⌘+S
(or Ctrl + S) in Google Docs?

Preventing default actions

			element.addEventListener("keyup", evt => {
				if (evt.key === "S" and (evt.metaKey or evt.ctrlKey)) {
					evt.preventDefault();
					myApp.save();
				}
			})
		

Preventing default actions

You can, but should you?

• No hard and fast rule
• Match user expectations
• Don't remove feedback without replacing it
• What about keyboard shortcuts that conflict with the browser’s?

Some events cannot be prevented

• unload (but beforeunload can!)
• input (but its composite raw events can!)
• scroll (use overflow: hidden;)
• select (use user-select: none;)
• fullscreenchange
• resize

			element.addEventListener(eventName, evt => {
				if (!evt.cancelable) {
					console.log("This event cannot be prevented!");
				}
			})
		

Synthetic events

			name.addEventListener("input", evt => {
				console.log(evt.target.value);
			});

			name.value = "Lea";

			let evt = new InputEvent("input");
			name.dispatchEvent(evt);
		

We can also make our own events!

			let evt = new CustomEvent("itemadded", {
				detail: {index: 2}
			});
			list.dispatchEvent(evt);
		

Custom events on custom objects!

				class GithubAPI extends EventTarget {
					constructor() {
						super();
					}
					login() {
						// ...
						let evt = new CustomEvent("login", {name: "Lea"});
						this.dispatchEvent(evt);
					}
				}
			

				let github = new GithubAPI();
				github.addEventListener("login", evt => {
					greeting.textContent = `Hi ${evt.detail.name}!`; // display user info
				});
			

Why fire our own events?

[Decoupling](https://en.wikipedia.org/wiki/Coupling_(computer_programming)), decoupling, decoupling!