Most interesting apps are stateful. They save information for later in some kind of database. This can make them harder to test, since each test could change the state of the app, making subsequent tests unpredictable. We're going to learn how to write tests that work with our database.

Setup

1. Download the starter files

2. Change into the workshop directory

3. Create a local DB by running: ./scripts/create_db

4. Populate the DB by running: ./scripts/populate_db

5. Start the server with npm run dev and check it's working

There is a very minimal Cypress testing setup. You can start Cypress with npm test—you should see the single example test from cypress/integration/test.js.

Isolating tests

It's easy to create tests that rely on each other. For example imagine we had an app for managing different types of dogs. Here are two example tests; one checks that creating a dog works, and one checks that deleting a dog works:

describe("Dog forms", () => {
  it("creates a new dog", () => {
    cy.visit("/");
    cy.get("input[name='dogName']").type("rover");
    cy.get("button[type='submit']").click();
  });
  it("deletes a dog", () => {
    cy.visit("/");
    cy.get("button[aria-label='Delete rover']").click();
    // make sure that Rover entry is removed from page
    cy.contains("Rover").should("not.exist");
  });
});

These tests work fine together, but if we ran the delete test on its own it would fail. It expects there to already be a dog called "Rover" in the database, but this only happens if the creation test runs first.

This is a bad idea since it makes tests brittle. If somebody comes along later and swaps the order of the tests (or removes a test) it could break things. Tests should always be self-contained and able to run on their own.

Resetting state between tests

Cypress has a handy way to run some code before every test—the beforeEach method. You can pass this a function and Cypress will run it before each test:

describe("Dog forms", () => {
  beforeEach(() => {
    console.log("I run before every test!");
  })
  it("creates a dog", () => {...})
  it("deletes a dog", () => {...})
})

We can use this to reset our database before each new test runs.

Unfortunately there's a slight complication: all the code inside our test runs in the browser. The browser doesn't have access to our Node environment, so it can't talk to our database directly.

However Cypress provides a way to execute code in your Node environment: "tasks". These are special functions you can create and then call from inside tests. Tasks are defined inside cypress/plugins/index.js:

module.exports = (on, config) => {
  on("task", {
    resetDb: () => {
      console.log("Resetting DB...");
      // we have to return something or Cypress gets mad
      return null;
    },
  });
};

We can then call this task in our tests like this:

beforeEach(() => {
  cy.task("resetDb");
});

Try creating this task now, and make sure you can call it from inside a test. You should see the log show up in your terminal, not the test browser (remember tasks are for running Node code outside the browser).

Running the populate_db script

We already have a script that can reset our DB back to its initial state: ./scripts/populate_db. We can re-use this within our Cypress task using Node's child_process module. This allows us to run terminal commands from inside Node.

In this case we want to use the execFileSync method to execute a given file:

// cypress/plugins/index.js

const { execFileSync } = require("child_process");

module.exports = (on, config) => {
  on("task", {
    resetDb: () => {
      console.log("Resetting DB...");
      return execFileSync("./scripts/populate_db");
    },
  });
};

Challenge 1: write some tests

Now you can finally write some tests without worrying about the DB.

1. Add a test verifying the / route displays a list of users

2. Add a test verifying you can create a user from the /create-user route

3. Add a test verifying you can delete a user from the / route

Modularising database queries

Currently we're querying our database directly within our route handler functions. It's generally a good idea to separate out data access. Ideally our route handlers shouldn't have to do anything more than call a function like getUsers(). That way we could e.g. swap from Postgres to a totally different DB without having to change our route handlers at all.

The nice thing about already having tests is refactoring becomes much safer. You'll find out quite quickly if you break something.

Let's extract the homepage's query. Create a new file workshop/database/model.js. Since there aren't many we'll put all our SQL queries into this one file.

Create a function named getUsers. Import your database pool object and use it to get all the users, just like before:

const db = require("./connection.js");

function getUsers() {
  return db.query("SELECT * FROM users");
}

module.exports = { getUsers };

You can now import and use this function in routes/home.js:

const model = require("../database/model.js");

function get(request, response) {
  model.getUsers().then((result) => {
    const users = result.rows;
    // ...
  });
}

This should work, but we can improve it. Our handler is stuck dealing with database-specific details. I.e. it has to know about the Postgres result.rows property. Ideally we should do this data-processing inside model.js instead:

const db = require("./connection.js");

function getUsers() {
  return db.query("SELECT * FROM users").then((result) => result.rows);
}

module.exports = { getUsers };

const model = require("../database/model.js");

function get(request, response) {
  model.getUsers().then((users) => {
    // ...
  });
}

Challenge 2: modularise queries

Move the rest of the DB queries into model.js. Make sure all the tests keep passing!

1. Write a createUser function to insert new users

2. Write a deleteUser function to delete a user

3. Write a getPosts function to select all the blog posts

4. Refactor your route handlers to use the new model functions

Modern CSS has powerful tools for controlling where elements go on the page. We're going to learn how to create style "primitives" (single-purpose bits of CSS) to solve different layout requirements, then see how we can combine those primitives together to create more complex layouts.

Layout fundamentals

Let's quickly review some of the ways we can control layout with CSS.

Flow layout

Flow layout is the default way elements behave. Block elements like div, header and p take up the full-width of the page. Inline elements like span, strong and a only take up as much horizontal space as they need, and can sit next to each other.

The viewport scrolls vertically by default, when there's too much content to fit on the screen. If the content is too wide to fit the browser will wrap elements onto the next line.

You can go a surprisingly long way without writing much layout CSS, since the defaults are pretty good.

Flexible box layout

Flexible box layout (usually called "flexbox") is an alternate layout context you can set using the display: flex rule.

This allows a parent element to control how its children are laid out. By default it puts elements all on a single line (as if they were inline elements). Unlike inline elements they won't wrap when there's not enough room. You have to enable wrapping with the flex-wrap: wrap rule.

Flexbox is usually used for single-direction layouts. I.e. a row or a column, but not both. It's also better for flexible layouts where you don't need exact control over where every element goes.

Grid layout

Grid layout is another layout context that lets a parent element specify rows and columns for its children to slot into. You set this using display: grid.

Grid can be used to create very specific layouts using grid-template-columns and grid-template-rows to specify an exact layout grid. You can then place child elements into specific locations on the grid with grid-column and grid-row.

Grid is usually used for two-direction layouts. I.e. rows and columns. It works best when you have a specific grid in mind, but can be less flexible.

The Center: constraining content width

It's important for content not to get too wide. Otherwise text gets pretty hard to read as your eyes have to travel so far left-to-right.

So it's a common requirement to put content in a narrow horizontally centered column. For example the content on this very website is in a center column.

The best way to constrain width is with the max-width property. This is better than just width, as it allows content to shrink if the viewport is too small. E.g. if you set width: 60rem but the viewport was only 40rem wide the element would overflow by 20rem.

.center {
  max-width: 30rem;
}

<div class="center">
  <div class="box">Box 1</div>
</div>

.example-center { max-width: 30rem; } Box 1Constaining max-width

We can then use margin to control where the constrained column goes. Setting margin to auto tells the browser to use as much of the leftover available space as possible. E.g. if we set margin-left: auto it would push the element all the way to the right (since the left margin would take up all of the available space):

.center {
  max-width: 30rem;
  margin-left: auto;
}

Box 1Left auto-margin example

To center an element we can balance this out with an equal margin-right: auto. Now both margins will get half the available space, pushing the element to the middle.

.center {
  max-width: 30rem;
  margin-left: auto;
  margin-right: auto;
}

Box 1Left and right auto-margin example

Customising width

We're going to need control over how wide the Center allows content to get, otherwise it's not very re-usable. We can control this in a couple of ways.

First we could use a CSS variable for the max-width:

.center {
  max-width: var(--max-width, 30rem);
  margin-left: auto;
  margin-right: auto;
}

This will default to 30rem if no variable is set, but we can override it if needed:

<div class="center" style="--max-width: 10rem">
  <div class="box">Box 1</div>
</div>

Box 1Narrower Center example

This is very easy to use, but has a couple of disadvantages. First it allows any value to be used. This is flexible but will lead to inconsistency in our design. It's better to pick pre-determined "allowed widths" so your layout doesn't look random.

Second, CSS variables are inherited, which means nested Centers will use the --max-width from their parent.

<div class="center" style="--max-width: 60rem">
  <div class="center">
    <div class="box">Box 1</div>
  </div>
</div>

You might expect the second .center here to be 30rem wide, since that's the default. However it will inherit the --max-width: 60rem from its parent, which is unexpected.

Instead of CSS variables we can define "modifier" classes that we apply to override the max-width rule:

.center {
  max-width: 30rem;
  margin-left: auto;
  margin-right: auto;
}
.width-sm {
  max-width: 20rem;
}
.width-lg {
  max-width: 40rem;
}
.width-xl {
  max-width: 60rem;
}

Now we can add extra classes when we want different widths.

<div class="center width-xl">
  <div class="center">
    <div class="box">Box 1</div>
  </div>
</div>

Challenge 1: using the Center

You're going to fix the layout of this page. Currently all the content is full-width and it's hard to read. Download the starter files using the command at the start of the workshop, then open challenge-1/index.html in your editor.

Challenge 1 preview

The header content should be constrained to 60rem wide, the first section to 40rem wide, and the contact section to 20rem wide.

Add the Center CSS you need to the style tag at the top. Then add classes to the HTML, but don't change it in any other way. Here is the result you're aiming for:

Challenge 1 solution

The Stack: controlling vertical space

The most important layout primitive is one to control the space between elements. For re-usability and simplicity it's a good idea not to apply spacing rules to individual elements. E.g. if you put margin-left on a button you can only re-use it in places where left spacing makes sense.

It's better to use a parent element to apply spacing to its children. This is often called a "stack". There are lots of ways to implement this (e.g. using flexbox or grid), but for simplicity we're going to do it with margin.

Let's say we want 1rem of space between each of these boxes:

<div>
  <div class="box">Box 1</div>
  <div class="box">Box 2</div>
  <div class="box">Box 3</div>
</div>

Box 1Box 2Box 3Boxes with no space between them

We could add styles to our .box class, but then we couldn't re-use those boxes in other places where margin-top didn't work. Instead we can use the parent to add margin to its children:

.stack > * {
  margin-top: 1rem;
}

<div class="stack">
  <div class="box">Box 1</div>
  <div class="box">Box 2</div>
  <div class="box">Box 3</div>
</div>

.example-stack > * { margin-top: 1rem; } Box 1Box 2Box 3Boxes with space above all of them

This isn't quite right: we've got space above every child—we only want the space between the children. This means no space above the first child.

There are a few ways to achieve this. We could add a rule disabling the margin for the first child:

.stack > * {
  margin-top: 1rem;
}
.stack > *:first-child {
  margin-top: 0;
}

Or we could only apply the rule to elements that are not the first child:

.stack > *:not(:first-child) {
  margin-top: 1rem;
}

Or we could use the adjacent sibling combinator to only apply the rule to elements that have a sibling before them:

.stack > * + * {
  margin-top: 1rem;
}

.example-stack-owl > * + * { margin-top: 1rem; } Box 1Box 2Box 3Boxes with space between them

Customising spacing

Our stack primitive is useful, but we're going to need different amounts of spacing to make a whole page. We can control this using multiple classes, just like with the Center.

This is nice because it allows us to choose a pre-set number of sizes, which keeps our layout consistent.

.stack-sm > * + * {
  margin-top: 0.5rem;
}
.stack-md > * + * {
  margin-top: 1rem;
}
.stack-lg > * + * {
  margin-top: 2rem;
}
.stack-xl > * + * {
  margin-top: 4rem;
}

Now we can control the space more easily:

<main class="stack-xl">
  <section class="stack-md">
    <div class="box">Box 1</div>
    <div class="box">Box 2</div>
    <div class="box">Box 3</div>
  </section>
  <section class="stack-md">
    <div class="box">Box 4</div>
    <div class="box">Box 5</div>
    <div class="box">Box 6</div>
  </section>
</main>

.example-stack-md > * + * { margin-top: 1rem; } .example-stack-xl > * + * { margin-top: 4rem; } Box 1Box 2Box 3Box 4Box 5Box 6Nested stacks with differing space between them

Challenge 2: using the Stack

You're going to use the Stack to fix the layout of a web page. Open challenge-2/index.html in your editor.

Challenge 2 preview

Currently there's no space between anything. There should be 2rem of space between each section. There should be 1rem of space between the elements within each section. There should be 0.5rem between each form field and its label.

Fix the layout by defining Stack CSS inside the style tag, then only adding Stack classes to the HTML. Don't add or remove any elements or write any other CSS! You can create this whole layout using only Stacks.

Challenge 2 solution preview

The Row: placing elements next to each other

Another very useful layout primitive is a "row". Web interfaces often need elements placed next to each other. For example a horizontal list of links in a navigation bar, or the "Confirm" and "Cancel" buttons in a dialogue popup.

Are you sure you'd like to delete everything? Delete CancelButtons sitting next to each other in a row

Flexbox is designed for one-dimensional layouts, so it is perfect here. Setting display: flex on an element lets it control how its children are laid out. By default they will all be put in a single row.

.row {
  display: flex;
}

.example-row { display: flex; resize: horizontal; overflow: hidden; border: 0.5rem solid; } .box { } These boxes are as big as their contentThese boxes are as big as their contentFlex container example

Making it responsive

If you resize the container using the handle on the bottom right you'll see that this layout doesn't adapt. By default the flex children will shrink as much as their content allows, but they can't get smaller than the longest word inside them. Once the container gets narrower than this they stop shrinking and get cut off.

This means our layout isn't flexible enough to cope with different screen sizes. Generally when you put things in a row you want to make sure they can wrap when there's no more space.

.row {
  display: flex;
  flex-wrap: wrap;
}

These boxes are as big as their contentThese boxes are as big as their contentFlex wrap example

Resizing this example shows the right-most child wrapping onto a new line when there isn't enough space for it.

What about media queries?

Note that we don't need to add media queries here. Those are great when you need really specific control over exactly how and when the layout should change. But this layout is intrinsically responsive. It flows to fit whatever container it is inside based on its content. This tends to be simpler and more robust than trying to figure out exactly what breakpoints to add in media queries.

Spacing children out

Layouts usually require some space between each element. CSS has a handy property for controlling this for flexbox and grid containers: gap. This is a shorthand for row-gap and column-gap, which allow you to control the vertical/horizontal spacing separately.

.row {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}

These boxes are as big as their contentThese boxes are as big as their contentFlex gap example

Note that the gap is maintained even when the children wrap. Using gap for flexbox is quite new, but it is supported by all modern browsers. If you need to support older browsers you can approximate the same effect using margins, but it's more complex to make sure it handles wrapping.

Alignment

Flexbox allows control over how children are aligned both horizontally and vertically. Most of the time you want things vertically centered, so that different height children line up. You can control vertical alignment with align-items:

.row {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
  align-items: center;
}

Small boxTall boxFlex vertical alignment example

You can allow this value to be customised the same way we did for the Stack's space above. Either a CSS variable or modifier classes:

.row {
  /* ... */
  align-items: var(--align, center);
}

.row {
  /* ... */
  align-items: center;
}
.align-start {
  align-items: start;
}
.align-end {
  align-items: end;
}
/* etc */

You may also need to allow control of horizontal alignment using the justify-content property. This lets the container push its children apart, or to either end of the container.

.row {
  /* ... */
}
.justify-end {
  justify-content: flex-end;
}

<div class="row justify-end">
  <div class="box">Box 1</div>
  <div class="box">Box 2</div>
</div>

Box 1Box 2Flex horizontal alignment example

Challenge 3: using the Row

Open challenge-3/index.html in your editor. You should see a page with a header containing a logo and a nav.

Challenge 3 preview

You need to make the header layout work correctly. The logo should be on the far left, with the nav on the far right, and all the links in a row, like this:

Challenge 3 solution

Again, only add Row CSS to the style tag and classes to the HTML. Don't add any new HTML elements.

The Grid: equal-sized children

Sometimes you need to create a grid of elements, like an image gallery. Every element should be the same size, and the grid should automatically put as many elements as it can in a row.

CSS grid is perfect for this. It lets us create a two-dimensional layout (with columns and rows), and keeps all the elements consistently sized (unlike flexbox).

We can make a grid and set a specific number of columns. We can also use gap to space the columns out:

.grid {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  gap: 1rem;
}

<div class="grid">
  <div class="box">Box 1</div>
  <div class="box">Box 2</div>
  <div class="box">Box 3</div>
  <div class="box">Box 4</div>
  <div class="box">Box 5</div>
  <div class="box">Box 6</div>
</div>

Here we're defining three columns that take up one fraction (1fr) of the available space. So they'll all be the same size.

.example-grid { display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 1rem; resize: horizontal; overflow: hidden; } Box 1Box 2Box 3Box 4Box 5Box 6Three-column grid example

The children automatically get slotted into new rows, but there are always three columns. This isn't very responsive: if you resize the example you'll see the boxes get squished.

The solution is a fancy CSS trick that tells the grid to automatically create as many columns as it can fit:

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(10rem, 1fr));
  gap: 1rem;
}

This rule will create as many equal-sized columns as it can, as long as they don't get smaller than 10rem. As the viewport gets bigger it'll add columns; as the viewport gets smaller it'll remove them.

.example-grid-dynamic { display: grid; grid-template-columns: repeat(auto-fit, minmax(10rem, 1fr)); gap: 1rem; resize: horizontal; overflow: hidden; } Box 1Box 2Box 3Box 4Box 5Box 6Three-column grid example

Resize the example and you should see the grid automatically reflow to fit the available space.

Challenge 4: bring it all together

For the final challenge you'll be recreating the Instagram Web profile layout—without writing any CSS at all.

Here's how it currently looks:

Challenge 4 preview

And here's what you're aiming for:

Challenge 4 solution

Open challenge-4/index.html in your editor. You need to get as close to the final layout as you can by only adding classes to the HTML. No touching the CSS!

It's important to get comfortable manipulating the Document Object Model (DOM) using JavaScript. This includes creating new elements, updating content, toggling classnames and removing elements.

Quick overview

Here is a quick overview of various DOM manipulation techniques. If you want to find out more about each one you can check their MDN articles.

Accessing elements

You can access elements on the page with the document.querySelector method. This takes any valid CSS selector (like "button" or "#my-id > .my-class:first-child") and searches the DOM for the first match. It returns a DOM element represented as a JS object.

You can access multiple elements with the document.querySelectorAll method. This works in the same way except it returns a NodeList of all matches.

A NodeList is similar to an array but missing most of the usual array methods (it only has .forEach). If you need to use .map/.filter etc you can turn it into an array with Array.from(myList).

Creating elements

You can create a new DOM element with document.createElement. This takes a tag string like "button" and returns the new DOM object.

It's important to note that this object isn't actually on the page yet—it just lives in memory in your JavaScript. To get the element to show up you have to put it inside another element on the page.

You can do this using the parent.appendChild or parent.append methods. The main difference between these is that append works for text and can take multiple items. E.g. myDiv.append(myButton, "some text", myParagraph).

Updating elements

Attributes

Most element attributes are reflected as JavaScript properties on the corresponding DOM object. For example the id attribute can be changed on a DOM object using dot-notation:

const myButton = document.querySelector("button");
// myButton is an object representing the DOM element
// it has properties for all its attributes

myButton.id = "my-id";
// if we change a property the DOM element will be updated

Some attributes are not accessible as object properties. This notably includes ARIA attributes (like aria-label). To change these you must use myEl.setAttribute and myEl.removeAttribute.

This works fine for simple stuff, but for attributes that are lists of strings (like className) it can be awkward. You often want multiple classnames set on an element, but this requires you to manually concatenate strings together.

const myButton = document.querySelector("button");

myButton.className = "btn btn--primary btn--large";
// whoops we overwrote any classes that were already applied

There is a nicer way to manipulate lists like this: the DOMTokenList methods. E.g.

• myElement.classList.add("my-class")

• myElement.classList.remove("my-class")

• myElement.classList.toggle("my-class")

• myElement.classList.contains("my-class")

Content

You can change the text inside an element by setting the textContent property. Be careful though—this will override all existing content, including other DOM elements inside.

You can also use the .append method to add text inside an element. This will work even if there are already other elements inside.

Styles

You can directly add inline styles to an element by setting properties on the myEl.style object. This can get awkward for setting lots of styles, so a simpler way is to add a classname using JS and write the corresponding styles in the CSS instead.

.highlight {
  background-color: yellow;
  padding: 0.5rem;
}

myButton.classList.add("highlight");
// instead of:
// myButton.style.backgroundColor = "yellow"
// myButton.style.padding = "0.5rem" etc

Challenge

Download the starter files and open challenge/dom.js. Your task is to complete as many of these functions as possible. Each should have a comment explaining what it should do.

You can check if each one is working by opening challenge/index.html in your browser. There's a section for each part of the challenge. Don't forget to check the console if something isn't working!

You may have used promises provided by libraries or built-in functions before. For example:

fetch("/test")
  .then((response) => console.log(response))
  .catch((error) => console.error(error));

A promise is an object with a .then method. This method takes a callback function that it will call with the result when the promise is finished (or "resolved"). You can imagine a promise object looks something like this:

// this isn't really how they work
// but it's a good mental model to start with
const promise = {
  then: (callback) => {
    // magically wait until result is ready somehow
    callback(result);
  }
  catch: (callback) => {
    // magically wait until an error happens somehow
    callback(error);
  }
}

But how do you create your own promise objects?

Creating promises

You can create your own promise objects with new Promise(). You have to pass in a function that defines when the promise will resolve or reject. This function is passed two arguments: resolve and reject. These are functions you call with the value you want to resolve/reject with.

For example:

function doSomethingAsync() {
  const promise = new Promise((resolve, reject) => {
    // do some async stuff that might error
    if (error) {
      reject(error);
    } else {
      resolve(result);
    }
  });
  return promise;
}

You could use the above just like any other promise-returning function:

doSomethingAsync()
  .then((result) => console.log(result))
  .catch((error) => console.error(error));

Challenge one

You're going to create a promisified version of setTimeout, called wait. It should take a number of millliseconds to wait as an argument, set a timeout for that long, then resolve the promise.

It should be usable like this:

wait(1000).then(() => console.log("done"));
// (after 1000ms) Logs: "done"

You can run the tests to check if your solution works:

npm run test:one

Challenge two

You're going to create your own promisified wrapper of Node's fs.readFile method. It usually takes a callback to be run when it finishes its asynchronous task.

Implement the readFilePromise function so that it returns a new promise. It should use fs.readFile to read whatever file path is passed in, then resolve with the result. It should reject with any error that occurred. For example:

readFilePromise("./test.txt")
  .then((contents) => console.log(contents))
  .catch((error) => console.error(error));

You can run the tests to check if your solution works:

npm run test:two

Setup

1. Download starter files

2. Run npx servor workshop to start a dev server

We'll be using three different methods to render the same dynamic UI to compare them. The UI will include a static single element (the title), plus a list of dynamic elements rendered from an array.

There is an array of dog objects in workshop/dogs.js. In each challenge you'll need to import that data and render the following UI:

<h1>All the dogs</h1>
<ul>
  <li class="card">
    <h2>Dog name</h2>
    <img src="dog image url" alt="" />
  </li>
</ul>

with a list item for each dog in the array.

The HTML document contains a single container to render all the UI into: <div id="app"></div>.

document.createElement

The standard way to create new DOM elements in JavaScript is the document.createElement method. You pass in a string for the HTML element you want to create and it returns the new DOM node. You can then manipulate the node to add attributes and content.

Appending nodes

Once you've created DOM nodes you have to append them to their parent (and eventually to a node that is actually on the page). The classic way to do this is element.appendChild(newNode). This puts newNode inside the element node. If element is already on the page then newNode is rendered.

This has a big drawback: you can only append one thing at a time. This can lead to inefficient rendering. Each time you append a new element to the page the browser has to re-render everything. It's better to get all your DOM nodes ready then append them to the page in one go.

There's a newer method with a nicer API: element.append. This is supported by all browsers but IE11. It can take as many elements to append as you like, and it even supports strings to set text content.

container.append("Some text", newNode, anotherNode, "more text");

This is powerful when combined with the spread operator, as it means you can append an array of elements in one go:

const elements = dogs.map((dog) => createListElementSomehow(dog));
container.append(...elements);

Challenge 1

1. Open app.js and import the dogs array

2. Use document.createElement and append to render:

   • a page title

   • an unordered list

   • a list item for every dog in the array

3. Put all these elements inside the <div id="app"> in the HTML

Abstracting createElement

We can write our own function to make it simpler to create DOM elements. Ideally we'll be able to pass in a tag name, some properties and some children, and have all the document.createElement stuff handled automatically. E.g.:

const p = createEl("p", { id: "test" }, "Some text content");
// <p id="test">Some text content</p>

We'll create this in a new file create-element.js, so we can re-use it in multiple places if we need to.

function createEl(tag, props, ...children) {
  // ...
}

The ... is the rest operator—it gathers any additional arguments into an array. Any arguments after the props object will go into a single array named children.

First we need to create a new element using the tag argument:

function createEl(tag, props, ...children) {
  const element = document.createElement(tag);
}

then we need to append all the properties from the props object onto the DOM element:

function createEl(tag, props, ...children) {
  const element = document.createElement(tag);
  for (const prop in props) {
    element[prop] = props[prop]; // e.g. element.id = "test"
  }
}

Finally we need to append all the children to the new element. We already saw how append combines with the spread operator to add a whole array of children at once:

function createEl(tag, props, ...children) {
  const element = document.createElement(tag);
  for (const prop in props) {
    element[prop] = props[prop];
  }
  element.append(...children);
  return element;
}

Don't forget to return the new element! We now have a nice helper function that we can export to use in our other file.

Challenge 2

Use your new createEl function to refactor your previous solution. Does it simplify the code?

innerHTML

This method almost feels like cheating. If you set an element's innerHTML property to a string the browser will render it. This makes it a quick way to render a chunk of DOM, especially combined with template literals:

container.innerHTML = `<div>Hello ${name}</div>`;

There are a couple of downsides to this method. First innerHTML is considered a security risk. If you ever insert user input into an HTML string (like above) you run the risk of XSS attacks (cross-site scripting). A user could insert <script src="steal-credit-cards.js"></script> as the name variable, and your code would render that to the page, causing it to immediately execute.

It can also potentially be slow, since every time you change a node's innerHTML property the browser must completely scrap and recreate its entire DOM tree. If you (for example) keep appending to innerHTML in a loop you'll cause a lot of unnecessary re-renders. Nowadays browsers are so fast this is less of a concern.

Challenge 3

Use innerHTML and template literals to create the same UI as before.

Stretch goal: the <template> element

The template element is a special HTML element designed for rendering dynamic UI with JavaScript. The template (and all its contents) don't appear on the page. It's like a reusable stamp: you have to use JS to make a copy of the template, fill in the blanks, then append the copy to the page.

<!-- index.html -->
<template id="homeTemplate">
  <h1 class="title"></h1>
</template>

const template = document.querySelector("#homeTemplate");
const clone = template.content.cloneNode(true);
const title = clone.querySelector("h1");
title.textContent = "Hello world";
container.append(clone);

This is useful because we don't have to dynamically create elements: we can use the ones already created inside the template.

Challenge 4

Use the template element to create the same UI. You'll need to edit the HTML file too.

Defining templates in JS

It's a little annoying that templates have to be defined in the HTML file. We're doing all our rendering within JavaScript, so it would be nice to keep all the templates there too.

We can work around this by combining all three of our rendering methods. We can create a new template element within our JS, set its content using innerHTML, then clone that template whenever we need a copy. The template is never actually on the page, it just lives inside our JS.

const template = document.createElement("template");
template.innerHTML = `<h1 class="title"></h1>`;
// clone the template same as before

This also avoid the problems with innerHTML, since we won't be passing user input into it. Our only use of innerHTML will be the initial static markup.

Challenge 5

Remove your template elements from the HTML file and instead create them with JavaScript. Refactor your previous solution to use this technique.

Conclusion

All of these techniques are valid, and all have their place. It's good to understand the platform you're working with, even if you end up using a framework like React that handles lower-level DOM manipulation for you.

Cookies are an important part of authentication. We're going to learn how they allow your server to "remember" information about previous requests.

Cookie background

HTTP is a "stateless" protocol. This means each new request to your server is totally independent of any other. There is no way by default for a request to contain information from previous requests. Unfortunately it's quite hard to build a website without being able to remember things. For example "what has this user added to their shopping cart?" and "has this user already logged in?".

Cookies were introduced in 1994 as a way for web browsers to store information on behalf of the server. The response to one request can contain a cookie; the browser will store this cookie and automatically include it on all future requests to the same domain.

How cookies work

A cookie is just a standard HTTP header. A cookie can be set by a server including the set-cookie header in a response. Here's an example HTTP response:

HTTP/1.1 200 Ok
content-type: text/html
set-cookie: userid=1234

<h1>Hello</h1>

That set-cookie header tells the browser to store a cookie with a name of "userid" and a value of "1234".

This cookie is then sent on all future requests to this domain via the cookie request header. Here's an example HTTP request:

GET /about HTTP/1.1
accept: text/html
cookie: userid=1234

The server would receive this second request, read the cookie header and know that this request was made by the same user as before (with a "userid" of "1234").

Cookie attributes

Cookies also support extra attributes to customise their behaviour. These can be set after the cookie value itself, like this:

set-cookie: userid=1234; Max-Age=60; HttpOnly; SameSite=Lax

Expiry

By default a cookie only lasts as long as the user is browsing. As soon as they close their tabs the cookie will be deleted by the browser. This is useful for certain features (like a shopping cart), but less useful for keeping a user logged in.

The server can specify an expiry time for the cookie. This tells the browser to keep it around (even if the user closes their tabs) until the time runs out. There are two ways to control this: Expires and Max-Age. Expires lets you set a specific date it should expire on; Max-Age lets you specify how many seconds from now the cookie should last.

Security

Cookies often contain sensitive information. There are a few options that should be specified to make them more secure.

The HttpOnly option stops client-side JavaScript from accessing cookies. This can prevent malicious JS code (e.g. from a browser extension) from reading your cookies (this is know as "Cross-site Scripting" or XSS).

The Same-Site option stops the cookie from being sent on requests made from other domains. You probably want to set it to "Lax" (which is the default starting with Chrome v84). Otherwise there's a risk of other sites pretending to act on behalf of a logged in user (this is know as "Cross-site Request Forgery" or CSRF).

The Secure option will ensure the cookie is only set for secure encrypted (https) connections. You shouldn't use this in development (since your localhost server doesn't use https) but it's a very good idea in production.

Cookies in Node

Lets see how to set and read cookies using Node.

Setup

1. Download the starter files and cd in

2. npm install

3. npm run dev

Raw cookie headers

Setting a cookie

First lets set a cookie by adding a "set-cookie" header to a response manually. Add a new handler for the GET /example route:

server.get("/example", (request, response) => {
  response.set(
    "set-cookie",
    "hello=this is my cookie; HttpOnly; Max-Age=60; SameSite=Lax"
  );
  response.redirect("/");
});

Visit http://localhost:3000/example. You should be redirected back to the homepage. Open dev tools and look at the "Application" tab. Click on "Cookies" in the sidebar and you should be able to see the cookie you just set.

Reading a cookie

You can read the cookie on the server by looking at the "cookie" header. Edit your home handler:

server.get("/", (request, response) => {
  const cookies = request.get("cookie");
  console.log(cookies);
  response.send("<h1>Hello</h1>");
});

If you refresh the page now you should see "hello=this is my cookie" logged. If you delete the cookie using the Application tab of dev tools and refresh again the cookie log should be gone.

Working with cookies this way is quite awkward—everything is just a big string, and we'd have to manually parse any values we needed. Luckily Express comes with some built-in cookie methods.

Cookies with Express

Setting a cookie with Express

Express' response object has a cookie method. It takes three arguments, the name, the value, and an optional object for all the cookie options. It handles creating the "set-cookie" header string automatically.

Update your /example handler to use Express' cookie helper:

server.get("/example", (request, response) => {
  response.cookie("hello", "this is my cookie", {
    httpOnly: true,
    maxAge: 1000 * 60, // 60,000ms (60s)
    sameSite: "lax",
  });
  response.redirect("/");
});

This should create the exact same cookie as before.

Reading a cookie with Express

Since reading cookies isn't something every server needs Express doesn't come with it built-in. They provide an optional middleware you need to install and use.

npm install cookie-parser

const cookieParser = require("cookie-parser");

server.use(cookieParser());

This middleware works like the built-in body-parsing one. It grabs the "cookie" header, parses it into a nice object, then attaches it to the request for you to use.

So now you can access all the cookies sent on this request at request.cookies:

server.get("/", (request, response) => {
  console.log(request.cookies);
  // ...
});

You should see an object like this logged:

{ "hello": "this is my cookie" }

Removing cookies with Express

Express also provides the response.clearCookie method for removing cookies. It takes the name of the cookie to remove. When the browser receives this response it will delete the matching cookie. Add a new route to your server:

server.get("/remove", (request, response) => {
  response.clearCookie("hello");
  response.redirect("/");
});

If you visit http://localhost:3000/remove in your browser you should be redirected back to the home page, but the cookie will be gone.

Authentication

Cookies are useful for ensuring users don't have to keep verifying their identity on every request. Once a user has proved who they are (usually by entering a password only they know) it's important to remember that information.

"Stateless" authentication

There are two ways to use cookies for authenticating users. The first is often known as "stateless" auth. We can store all the information we need to know in the cookie itself. For example:

const userInfo = {
  id: 1,
  username: "oliverjam",
  admin: true,
};
response.cookie("user", userInfo, {
  httpOnly: true,
  maxAge: 1000 * 60,
  sameSite: "lax",
});

When the user first logs in we set a cookie containing the user's information. On subsequent requests our server can check for this cookie. If it is present we can assume the user has previously logged in, and so we allow them to see protected content.

Signing cookies

Unfortunately this has a pretty serious security problem: we can't trust cookies sent to us. Since a cookie is just an HTTP header anybody could send a cookie that looks like anything. E.g. anyone can use curl to send such a request:

curl -H 'cookie: user={"id":1,"username":"oliverjam","admin":true}' localhost:3000

It's also easy to edit cookie values in dev tools—a user could simply change their ID/username to another.

However there is a way we can trust cookies: we can sign them. In cryptography signing refers to using a mathematical operation based on a secret string to transform a value. This signature will always be the same assuming the same secret and the same input value. Without the secret it is impossible to reproduce the same signature.

If we sign our cookie we can validate that it has not been tampered with, since only our server knows the secret required to create a valid signature. Implementing this from scratch would be complex and easy to mess up—luckily the cookie-parser middleware supports signed cookies.

server.use(cookieParser("alongrandomstringnobodyelseknows"));

server.get("/", (request, response) => {
  console.log(request.signedCookies);
});

server.get("/example", (request, response) => {
  response.cookie("hello", "this is my cookie", { signed: true });
  response.redirect("/");
});

You need to pass a random secret string to the cookieParser() middleware function. Then you can specify signed: true in the cookie options. Signed cookies are available at a different request key to normal cookies: request.signedCookies.

Challenge 1: stateless auth

1. Add a GET /login route that sets a signed cookie containing some user information, then redirects to the home page

2. Add a GET /logout route that removes the cookie, then redirects to the home page

3. Log the signed cookies in the home route

If you visit /login you should see the cookie data you set logged in your terminal. In the browser's dev tools the cookie will have some extra random stuff attached to it. This is the signature.

s:j:{"id":1,"username":"oliverjam","admin":true}.uJLn0/18tqme8pQE0bB+8WsqeEXP2IY19l+34YdyFnk

If you edit the cookie in dev tools and then refresh you should instead see your server log false for that cookie name. This is because the signature no longer matches, so the server does not trust the cookie.

If you visit /logout the cookie should be removed from your browser.

Stateless auth downsides

Storing all the information we need inside the cookie like this is very convenient. However there are some downsides:

1. Cookies have a 4kb size limit, so you can't fit too much info in them.

2. The cookie is the "source of truth". This means the server cannot invalidate a cookie, it has to wait for the cookie to expire. The server cannot log users out—as long as their cookie is valid they can keep making requests.

Server-side session authentication

The other way to keep users logged in is to keep track of that state on the server. The cookie just stores a unique ID. This ID refers to some data that lives on the server and stores all the user info.

For example once a user logs in you might set a cookie containing a session ID like this:

set-cookie: sid=abcd; HttpOnly; Max-Age=60;

and then store the relevant user info using that sid as a key:

let sessions = {};

// later
sessions["abcd"] = { id: 1, username: "oliverjam", admin: true };

Here we're just putting the session data in an object, which means it will get deleted whenever the server restarts. Ideally this information would be stored in a database so it persists.

On subsequent requests the server would read the session ID cookie, then use that to look up the user info from the sessions object.

server.get("/", (request, response) => {
  const sid = request.signedCookies.sid;
  if (sid) {
    const userInfo = sessions[sid];
    console.log(userInfo);
  }
  response.send("<h1>Hello</h1>");
});

This allows the server to control the "session"—if it needs to log a user out it can simply delete that entry from the sessions storage.

Security

It's important that the session ID is a long random string, so that nobody can guess them. Here's a good way to generate a random 18 byte long string in Node:

const crypto = require("crypto");

const sid = crypto.randomBytes(18).toString("base64");
// "MqLV99hG294x5+Q+gm5gHnbH" (this will be different every time)

Also although we aren't directly storing user info in the cookie we still need to sign it. Otherwise if someone did find a way to guess the session IDs they could edit their cookie.

Challenge 2: session auth

1. Change your GET /login route to set a signed session ID cookie. This cookie should just contain a long random string

2. Store the user data in a global sessions object

3. Change the home handler to read the session ID cookie, look the user info up in the global sessions object, then log it

4. Change the GET /logout route to remove the cookie and delete the session from the global sessions object

There are lots of useful modules on npm that can help us when we're working. Writing code can be difficult and error-prone, when you're learning and even when you're experienced. There are certain parts that are worth automating so you can free up your brain to worry about more interesting problems.

Formatting with Prettier

The JS ecosystem has mostly settled on using the Prettier library to format their code. This ensures that everyone's code looks the same, which makes it easy to jump into new projects. It's nice to automate things like indentation or quote usage, since these are not really things you want to waste brainpower on while you are coding.

Using Prettier

There are a couple of ways to use Prettier to format your code. The simplest is to install an extension for your editor. Here is the VS Code extension. You can then configure your editor to "format on save", so your code is always formatted correctly.

You should also install Prettier as a dependency in your project. This ensures anyone who contributes will get the same version. Otherwise someone with an older version of the editor extension might end up formatting some code differently to the rest.

You want to install it as a development dependency, since it is not needed for your actual app code to work:

npm install -D prettier

The Prettier extension will automatically use the locally installed version, so everyone should end up with consistent code.

If you like you can use the Prettier CLI to format code as well. This command will format all files in your current directory:

node_modules/.bin/prettier --write .

Configuring Prettier

Prettier is explicitly designed to be very opinionated—the whole point is to make all code consistently formatted. However there are some things you can configure (like using single vs double quotes).

Create a .prettierrc.json file and put any config options in here. If you're happy with the default settings you can just use an empty object:

{}

This will ensure that everyone's editor extension uses the defaults instead of whatever they might have configured for their personal settings.

Linting with ESLint

ESLint is the most popular JS linter. A linter is a program that looks at your code and tries to find mistakes. You can think of it like a spell/grammar checker for code.

This is incredibly useful as a linter can easily find problems that are quite difficult for a human to spot. For example here's a simple bug:

function run(fileInput) {
  // imagine there are many lines in between here
  console.log(filelnput); // undefined 😱
}

ESLint would underline console.log(fileinput) in red, and tell you that fiileinput is undefined. Linters can also be helpful when you're learning, as some of their warnings will be about stuff you didn't know yet.

Installing ESLint

Similar to Prettier you want to install both the ESLint editor extension and the command-line tool. Here is the VS Code extension.

Again you'll want to install it as a development dependency:

npm install -D eslint

ESlint requires a bit more config, which you can automatically generate by running this command:

npm init @eslint/config

It will ask you some questions about your project, then generate a config file. Choose the JSON option—you should end up with a new file named .eslintrc.json that looks like this:

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": "eslint:recommended",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "rules": {}
}

This config "extends" the built-in recommended ruleset, which will catch common mistakes and problems. Later on if you need to you can add or disable specific rules in the "rules" object here.

Using ESLint

You may need to restart your editor after installing the ESlint extension. Afterwards you should start seeing red underlines for mistakes in your code. Try referencing an undefined variable like this:

console.log(xyz);

You should see a red underline—hover the variable and you'll see a popup with a message like 'xyz' is not defined. eslint(no-undef). The last bit is the specific rule being broken. If you ever don't understand a problem you can google this rule and read about it on ESLint's website for more information.

Development server

It's useful to have a local dev server when working on projects. Whilst it's possible to just open an .html file in your browser to view a webpage locally, lots of newer browser features won't work (for security reasons). A proper dev server also has nice features like "live reload" to auto-reload the page whenever you save changes to a file.

The "Live Server" VS Code extension is popular for this, as it makes it quick and easy to start a local server. However this isn't ideal for shared projects as you don't have a centrally configured way to run the site—you're relying on each contributor to bring their own server.

Browsersync is a nice tool for creating dev servers. You should install it as a development dependency:

npm i -D browser-sync

You can then start a server for your local files:

node_modules/.bin/browser-sync --server --watch

This is annoying to type so you probably want to add an npm script to your package.json:

{
  "scripts": {
    "dev": "browser-sync --server --watch"
  }
}

Now you can just run npm run dev to start the server.

Browsersync will watch all your files and auto-reload your browser tabs if you change them. It also synchronises browser state across all tabs/windows, so if you scroll or fill in a form in one tab it'll update all of them. This is handy for testing lots of viewport widths at once, for example.

It will also run the server on your local Wi-Fi network, so you can easily test your local work on a mobile device. When you start the server you'll see a log like: External: https://192..... Visit this IP address on any device on the same Wi-Fi network to see your local site.

Functions are variables

When you create a function in JS you are creating a normal variable:

function returnsOne() {
  return 1;
}
// we now have a variable named returnsOne

This is still true (and perhaps more obvious) for arrow functions:

const returnsOne = () => 1;

You can reference this variable the same way you would any other (using its name):

console.log(returnsOne);
// logs something like: `function returnsOne()`

Challenge

We can pass functions to other functions as arguments.

1. Write a function named logger

2. It should take one argument and log it to the console

3. Call logger with the returnsOne function as an argument

Answer ```js function logger(thing) { console.log(thing); } logger(returnsOne); // function returnsOne() ```

Functions are callable

The main distinction between a function and other types of variable is that you can call a function. You call a function by putting parens (normal brackets) after it:

returnsOne();

Calling a function will run the lines of code inside of it. We can either reference the called function directly or assign it to a named variable.

console.log(returnsOne()); // 1

const myValue = returnsOne();
console.log(myValue); // 1

If the function returns nothing you'll get undefined:

function returnsNothing() {
  // doesn't have a return statement
}
const myValue = returnsNothing();
console.log(myValue); // undefined

Challenge

This is often a source of confusion when passing functions as arguments.

1. Add another call to logger, but this time pass in returnsOne()

2. Why do we see a different value logged?

   Answer ```js function logger(thing) { console.log(thing); } logger(returnsOne); // Logs the function itself: `function returnsOne()` logger(returnsOne()); // Logs the function's return value: `1` ```

3. Edit logger to use typeof to log the type of the value

   Answer ```js function logger(thing) { console.log(typeof thing); } logger(returnsOne); // function logger(returnsOne()); // number ```

Inline functions

Another source of confusion is functions defined inline. This is a common pattern for passing functions as arguments to other functions (for example as event listeners):

window.addEventListener("click", (event) => {
  console.log(event.clientX, event.clientY);
});

Challenge

1. Type the event listener code into your editor

2. Extract the inline function and assign it to a variable

3. Use the extracted function as your event listener

Answer ```js const handleClick = (event) => { console.log(event.clientX, event.clientY); }; window.addEventListener("click", (event) => handleClick(event)); // OR window.addEventListener("click", handleClick); // We don't need an extra arrow function if all it does is // forward arguments on to the function we actually care about ``` It's important to note that we don't want to _call_ our function when we pass it here. This won't work as we need to pass a function, not its return value: ```js const handleClick = (event) => { console.log(event.clientX, event.clientY); }; window.addEventListener("click", handleClick()); // this is equivalent to: // window.addEventListener("click", undefined); // since handleClick doesn't return anything ```

Callbacks

"Callback" is a scary word, but you've actually been using them the whole time. A callback is a function passed to another function as an argument. The name refers to what callbacks are usually used for: "calling you back" with a value when it's ready.

For example the addEventListener above takes a function that it will call when the "click" event happens. We're telling the browser "hey, call us back with the event info when that event happens".

Functions are effectively a way to delay execution of a block of code. Without them all our statements would run in order all in one go, and we'd never be able to wait for anything or react to user input.

Challenge

1. Write a function one that takes a callback as an argument

2. It should call the callback with 1

3. Call your one function and pass in a callback that logs its argument

Answer ```js function one(callback) { callback(1); } one((x) => console.log(x)); // OR one(console.log); // the extra wrapper arrow fn isn't needed, since all it does // is forward its argument on to console.log (which is already a fn) ```

Async

The callback above might feel a bit pointless: why not just have the one function return 1? Callbacks make more sense when dealing with asynchronous code. Sometimes we don't have a value to return straight away.

For example network requests and timeouts can take multiple seconds to complete. JavaScript doesn't wait for these—it keeps on going and executes the next statements in the script.

console.log(1);
setTimeout(() => console.log(2), 1000);
console.log(3);
// 1, 3, then (after one second) 2

Our addEventListener from above can't return the click event, since it hasn't happened yet. So instead we pass a callback that it will run when it has the event.

Challenge

1. Write a function asyncDouble that takes 2 arguments: a number and a callback

2. It should use setTimeout to wait one second

3. Then it should call the callback argument with the number argument multiplied by 2

4. Call asyncDouble with 10 and a callback that logs whatever it is passed. You should see 20 logged after 1 second.

5. Can you see why asyncDouble can't just return the doubled value?

Answer ```js function asyncDouble(num, callback) { setTimeout(() => callback(num * 2), 1000); } asyncDouble(10, (x) => console.log(x)); // OR asyncDouble(10, console.log); // (after one second) logs `20` ```

Workshop

Let's make some traffic lights.

1. Write a function light that takes two arguments: a string and a callback

2. It should wait 1 second, log the string and then call its callback argument

3. Use light to log each colour of a traffic light sequence, in order, followed by "finished"

   • e.g. "green", "amber", "red", "amber", "green", "finished"

Bonus (if you have time)

Traffic light patterns are a bit more complex. The sequence should actually be "green", "amber", "red", "red" and "amber" (at the same time), "green". Without changing light, create the new sequence.

Cypress is a tool for automatically running your tests in a real web browser. Lots of testing libraries run using Node in your terminal. This means they struggle to test real user interactions with the DOM (since Node doesn't have one).

You can test in the browser by manually including test functions in a script tag on the page. However this isn't ideal as you have to remember to remove them from your production deployment (or all your users can see your test results in the console).

Cypress solves this problem by letting you write separate test files, then injecting them into a real browser. Since it automatically controls a browser you can see your tests running in in real time.

Setup

First we need to create a new directory and initialise it so we can install modules:

mkdir cypress-testing
cd cypress-testing
npm init -y

Once you're inside your new directory and have generated a package.json file you can install Cypress as a dev dependency:

npm install -D cypress

Cypress can take a while to install the first time, so be patient. Once it's finished open your package.json and edit the "test" script to this command:

{
  "scripts": {
    "test": "cypress open"
  }
}

Run npm run test in your terminal, and you should see the Cypress app start up. The window will show a bunch of example tests—don't worry about these for now.

The first time you run Cypress it automatically creates some files. You should see a cypress.json file and a cypress/ directory full of examples. The JSON file is used to configure Cypress—you can leave it empty for now.

Now you're ready to write your first test.

Your first Cypress test

By default Cypress looks in the cypress/integration/ directory for test files. It will run anything inside this folder. You can delete the auto-generated example/ folder, since we're going to start from scratch.

Create a new file called practice-tests.js. You should see this file show up in the Cypress app under "Integration tests".

You can click the file name to run it with Cypress. This should open up a browser with a "test sidebar" on the left. Since we didn't actually write any tests yet it'll say "No tests found".

Let's add a simple test to the file:

it("can run a test", () => {
  assert.equal(1, 1);
});

Cypress uses a global it function to define tests. This works just like the test function we wrote in the intro to testing workshop—it just has a different name.

If you save your test file Cypress should automatically re-run the test. It will now find the test and show the result in the sidebar.

This is a fine way to write simple unit tests, but Cypress is much more powerful. Let's test a real web page.

Add a new test function:

it("can navigate pages", () => {
  cy.visit("https://example.cypress.io/");
});

We're using the global cy object to run a "command". cy.visit tells Cypress to load a URL in the browser and wait for the page to load.

You should see the test re-run in your Cypress browser. The right side should load Cypress' example app (called "Kitchen Sink").

Let's add a command to find an element on the page:

it("can navigate pages", () => {
  cy.visit("https://example.cypress.io/");
  cy.contains("within");
});

cy.contains will search the text content of all elements until it finds a match. If you click this test in the sidebar you should see the "Test body" table. Hover the contains command and the browser on the right will update to highlight the element it found.

If a Cypress command fails it will cause the test to fail. For example change your test to search for an element containing "zzzzzz". You should see an error message in the sidebar.

Now let's interact with this element in our test:

it("can navigate pages", () => {
  cy.visit("https://example.cypress.io/");
  cy.contains("within").click();
});

This will tell Cypress to click the link. You should see the test re-run, and the browser navigate to the "Querying" page.

Finally we can make an assertion about the new page to verify that we got to the right place:

it("can navigate pages", () => {
  cy.visit("https://example.cypress.io/");
  cy.contains("within").click();
  cy.url().should("include", "/commands/querying");
});

This syntax is a little strange at first, but it's supposed to read like a sentence. The cy.url method retrieves the current URL. The .should method creates an assertion. Here we are checking that the URL includes the sub-string "/commands/querying".

That's it—we've created a full integration test with Cypress. It's important to note that we aren't limited to a single set of tasks in a test. We can keep adding more commands in here until we're satisfied.

Cypress commands

You can find a full set of available commands at https://example.cypress.io/. Here's a quick example with a few new ones that will useful:

cy.get("#signup-form").find("input[name='email']").type("my-email@test.com");
cy.get("#signup-form").submit();

Here we're getting the sign up form, finding the email input within it, then typing an email into that input. Finally we get the form again and submit it.

cy.get takes a CSS selector to find an element, just like querySelector in the DOM. .find works the same way, but it searches the children of an element. .type simulates typing text via the keyboard. .submit triggers a form submission.

Workshop

You're going to use Cypress to build a server TDD-style. That means write a failing test for each feature first, then implement that feature to make the test pass.

Quick setup

1. Create a server.js file

2. npm install express

3. npm install -D nodemon (for auto-restarting the server)

4. Add a "dev" npm script of: nodemon server.js

Write your Express server in server.js. Write your tests in cypress/integration/.

Requirements for your server

• / page with a title of "Welcome to my site"

• / page has working links to /about and /sign-up

• /about page with a title of "About this site"

• /sign-up page with a form containing email/password inputs

• /welcome page with a title of "Thanks for joining"

• /sign-up page redirects to /welcome after form submission (don't worry about actually using the submitted data)

Stretch goal

If you have spare time go back to the server-side forms workshop. Use Cypress to write tests for your solution to verify that it works correctly

Git

Git is a a program for controlling versions of a project. It allows you to track changes you make to files over time.

To make an analogy, it's like having a save button on your project. At any time, you can save what you've written and mark that point in time. This means you can review versions of the code or go back to a previous version.

GitHub

GitHub, although similar in name, is not directly related to Git. GitHub is a platform for storing code online.

Each project is stored in a repository - this is a folder where all the files are contained on GitHub.

GitHub also allows you to host a live version of your website via GitHub Pages. You can share the link with anyone and they can visit websites that you've created!

Local vs. Remote

We'll describe repositories in terms of local and remote versions.

A local repository is a folder on your computer which you save files to. A remote repository is a folder online which your files can be duplicated to.

Workflow

When working with Git, you'll need to establish a workflow for synchronising code between a local and remote repository.

For example, if I change files on my computer, I'd like to then update the live version of a website by pushing my files to the remote repository. Or, if I'd like to download a project and create my own version, I might clone a remote repository to my local machine.

Once you've established a connection between your local repository and a remote one, you'll usually make changes on your local machine.

You can then stage the changed files - in other words, tell Git that you'd like these to be tracked in your version history. Staging is used to specify which changes to track, and which not to. For example, you might be ready to add your HTML and CSS files, but have unresolved errors in JavaScript. You can choose to stage some or all of your files.

Then next step is to commit your staged files - marking a save point in your project of the progress so far. Commits should contain a commit message which describes the changes made.

Finally, you'll push your local changes to the remote repository.

VS Code

A program you can download which lets you write and edit code on your computer. VS Code is one of the most popular text editors and offers a number of extensions which can be helpful to you as a developer.

VS Code's source control tab

The source control tab in VS Code allows you to use Git within your text editor. It's offers the ability to stage, commit and push changes between your local machine and a remote repository.

From here, you can continue to stage, commit and push your changes.

You should commit once you have completed a change or feature, not after writing certain amount of code, and don't wait until a project is complete. Getting into the habit of making small commits often will give you a good level of practice with Git. Regularly pushing your changes will ensure your codebase is backed up and version-controlled. Additonally, you'll have GitHub activity on your profile (green squares).

Deploying your website

In this workshop you'll learn how to validate user input in the browser and present error messages accessibly.

Setup

1. Download starter files

2. Open workshop/index.html in your browser

3. This is the form we'll be adding validation to

Why validate in the browser?

Client-side validation is important for a good user experience—you can quickly give the user feedback when they need to change a value they've entered. For example if passwords must be a certain length you can tell them immediately, rather than waiting for the form to submit to the server and receive an invalid response.

Communicating requirements

Our form has two inputs: one for an email address and one for a password. These are the requirements we need to validate:

1. Both values are present

2. The email value is a valid email address

3. The password contains at least one number, and is at least 8 characters long

Before we implement validation we need to make sure the user is aware of the requirements, by labelling the inputs. There's nothing more frustrating than trying to guess what you need to do to be able to submit a form.

Required values

Different types of value

If we don't list our password requirements users will have to guess what they are.

The simplest way to list requirements is in a <div> following the label. This is fine for visual users but won't be linked to the input, which means assistive tech will ignore it.

Challenge

1. Add a visual required indicator to both inputs.

2. Add instructions containing our password requirements

3. Associate the instructions with the input using aria-describedby

If you inspect the password input in Chrome's devtools you should be able to see the accessible name (from the label) and description (from the div) in the "Accessibility tab".

HTML5 validation

Now we need to tell the user when they enter invalid values. Browsers support lots of different types of validation.

Requiring values

The required attribute will stop the user submitting the form if they haven't entered this value yet.

<input required />

Types of values

Browsers will validate certain input types to make sure the value looks correct. For example:

<!-- checks the value is an email string -->
<input type="email" required />
<!-- checks the value is a URL string -->
<input type="url" required />

Matching a pattern

We can specify a regex the value must match using the pattern attribute. For example this input will be invalid if it contains whitespace characters:

<input type="text" pattern="\S" />

Other validation

You can even style inputs based on their validity using CSS pseudo-classes like :invalid, :valid and :required.

Challenge

Ensure each input meets our validation requirements above. If you submit the form with invalid values the browser will automatically stop the submission and show a warning.

Custom validation

It's still useful to start with the HTML5 validation attributes, so that if our JS fails to load or breaks the user at least gets basic validation.

Hijacking the built-in validation

First we need to disable the native validation by setting the novalidate attribute on the form element. This prevents the built-in errors from appearing.

Then we can listen for the form's submit event and check whether any inputs are invalid using the form element's .checkValidity() method.

This method returns true if all inputs are valid, otherwise it returns false. If any of the inputs are invalid we want to call event.preventDefault() to stop the form from submitting. Don't worry about showing error messages for now.

Challenge

1. Open workshop/index.js

2. Disable the native form validation

3. Listen for submit events and check whether all the inputs are valid

4. Prevent the form from submitting if any inputs are invalid

Handling invalid inputs

We've managed to stop the form submitting invalid values, but we need to provide feedback to the user so they can fix their mistakes.

First we need to actually mark the input as "invalid". The aria-invalid attribute does this. Each input should have aria-invalid="false" set at first, since the user hasn't typed anything yet. Then we need to know when the input becomes invalid, so we can update to aria-invalid="true".

We can listen for an input's invalid event to run code when it fails validation. The browser will fire this event for all invalid inputs when you call the form element's checkValidity() method. E.g.

inputElement.addEventListener("invalid", (event) => {
  console.log(inputElement + " is now invalid");
});

The final step is showing a validation message depending on what type of validation error occurred. We can access the default browser message via the input.validationMessage property. E.g. for a required input this might be "Please fill out this field".

Challenge

1. Loop through all the inputs

2. Mark each as valid

3. For each input listen for the invalid event

   • Mark the input as invalid when this event fires

Validation messages

We need to actually tell the user what their mistake was. The simplest way to do this is to grab the built-in validation message from the browser. This will be available as the element.validationMessage property. For example if the user typed "hello" into this input:

<input type="email" />
<script>
  input.addEventListener("invalid", () => {
    console.log(input.validationMessage);
  });
</script>

The JS would log something like "Please include an '@' in the email address". These message vary across browsers.

We need to put the message on the page so the user knows what they did wrong. The message should be associated with the correct input: we want it to be read out by a screen reader when the user focuses the input.

We can achieve this using aria-describedby just like with our password requirements. This can take multiple IDs for multiple descriptions (the order of the IDs determines the order they will be read out).

<label for="password">Password</label>
<div id="passwordRequirements">
  Please enter at least 8 characters containing at least 1 number
</div>
<input
  id="password"
  type="password"
  aria-describedby="passwordRequirements passwordError"
  required
/>
<div id="passwordError">{insert the right message in here}</div>

Whenever this input is focused a screen reader will read out the label first, then the type of input, then any ARIA descriptions.

Challenge

1. Create divs to contain the error messages

2. Set attributes on the inputs and divs so they are linked together

3. Put the validation messages inside the divs so the user can read them

Re-validating

Right now it's a little confusing for the user as the input stays marked invalid even when they type something new. We should mark each input as valid and remove the error message when the user inputs something.

1. Add an event listener for input events

2. Mark the input valid and remove the error message

Styling

We have a functional, accessible solution now, but it could be improved with some styling. It's common to style validation messages with a "danger" colour like red, and sometimes to mark invalid inputs with a different coloured border. You could also use warning icons to make errors even more obvious.

Challenge

1. Style the error messages

2. Style invalid inputs

3. Add any other styles you like to make it look good

Stretch goal: custom messages

The default browser messages could be better. They don't contain specific, actionable feedback. E.g. if a pattern doesn't match the user sees "Please match the requested format". It would be more useful to show "Please enter at least one number".

We need to know what type of error occurred to show the right custom message. The input element's .validity property contains this information.

This interface has properties for every kind of error. For example an empty required input will show:

{
  valueMissing: true,
  typeMismatch: false,
  patternMismatch: false,
  // ... etc
}

We can write an if/else statement to check whether each property we're interested in is true. If it is we can show a custom error on the page:

let message = "";
if (validity.valueMissing) {
  message = "Please enter an email address";
} else if (validity.typeMismatch) {
  // ...
}

Challenge

1. Edit your invalid handler to check the validity interface

2. Show custom error messages based on the input's ID and what validation failed.

Resources

Forms are the building blocks of interactivity on the web. They allow websites to send requests to servers without requiring any client-side JavaScript.

How forms work

You create a form with the <form> element. This is a container for all the different types of inputs your users will interact with.

Forms can contain any number of elements that allow user input (e.g. <input>). Users can enter values into these fields, then submit the form. The browser will then make a request to a new page that you specify, sending all the data from the form.

Inputs

The humble <input> element can be used to render many different types of input.

Different input types

There are many different types of input to cover all the various kinds of data you might want to collect from a user. You can see the full list and read more about each .

• <input type="text">

  Basic single line text input.

• <textarea></textarea>

  Allows multiline text input.

• <input type="email">

  Shows a special keyboard with the @ symbol on some phones. Also validates that the user entered an email on submission.

• <input type="checkbox">

  Used for turning specific values on or off.

• <input type="radio">

  Used for selecting one value out of a group of options.

Form submission

Forms can also contain button elements. By default clicking them will submit the form. It's generally a good idea to explicitly add type="submit" to your submit buttons (even though it's the default). That way it's obvious to other developers what the button does.

The action attribute

When submitted a form will send a request to the URL in its action attribute. This can be a relative URL within the same site (e.g. /submit) or an external URL to another site (e.g. https://example.com/submit).

This request is a standard GET request, just like when you type a URL manually (or click a link). When the browser receives a response to the request it will render that as a new page (just like when you click a link).

Submitting user data

All inputs with a name attribute within your form will be submitted. By default they'll be sent as the "search" part of the URL (often called the "querystring". It's the bit after the "?" at the end).

It will be structured like this:

example.com/submit?name=value&other-input=other-value

Each field is represented with its name and value separated by an ampersand (&).

Some input types submit differently. For example a checkbox can either checked or not. If it is unchecked it won't be sent at all. If it is checked but has no value attribute then it will be sent as name=on. If it has a value attribute that will be used instead. E.g.

?marketing-consent=my-value

Radio buttons are designed to select one value out of a set of options. A group of radios should use the same name to link them together. They should each have unique value attributes. The value of the selected radio will be submitted. E.g.

?contact-method=email

Workshop

Part One: basic request

1. Open workshop/index.html in your editor

2. Add a form to the page containing a text input

   • This should submit a name value

   • Don't forget inputs need labels!

3. The form should submit to "https://learn-forms.netlify.com/submit/part1"

4. The response will tell you whether you successfully submitted a name

Part Two: different input types

1. Change your form to submit to "https://learn-forms.netlify.com/submit/part2"

2. Add fields for:

   • an email address

   • a telephone number

   • a textarea for a message

   • a marketing-consent checkbox

3. The data submitted should look something like this:

   Copy

   name=Oli
   email=hello@oliverjam.es
   telephone=0123455678
   message=Hello this is a message!
   marketingConsent=on

Part Three: using radio groups

1. Change your form to submit to "https://learn-forms.netlify.com/submit/part3"

2. Add a group of three radios that allow the user to choose their preferred contact method (email, phone, post)

3. The extra data submitted should look like this (if email was selected):

   Copy

   contact=email

ES Modules are a way to isolate your JS files. This is similar to Node's require syntax, but build-in to the JS language (rather than a proprietary Node feature).

Modern browsers support modules loaded from a script tag with type="module". This tells the browser that this JS code may load additional code from other files.

<script type="module">
  import { add } from "./maths.js";

  add(1, 2);
</script>

Generally (for wider browser support) apps use a tool called a "bundler" to parse all the imports and "bundle" them into a single file that older browsers will understand. For ease of learning we won't be using a bundler yet.

Module scope

Modules help with JavaScript's global variable problem: usually variables defined in one file are able to be accessed (and changed) in any other. This can be confusing and dangerous, since you can't tell where things are defined/changed.

With modules variables defined in separate files are not accessible in another. This means you can have 100 variables named x, as long as they're all in different files.

The only way to use a value from another module is to explicitly export it from one file, then import it where you want to use it.

Exports

Files can have two types of exports: "default" and "named". A file can only have one default export, but can have many named exports. This is conceptually similar to the difference between module.exports = myFunction and module.exports = { myFunction, otherFunction } in Node.

This is how you create a default export:

const a = 1;
export default a;

And this is how you create a named export:

const a = 1;
export { a };

You can only default export a single thing, but you can have as many named exports as you like:

const a = 1;
const b = 2;
export { a, b };

You don't have to export things at the end of the file. You can do it inline:

export const a = 1;
export const b = 2;

Imports

There are also two kinds of imports: default and named. The way you import a value must match the way you exported it. A default-exported variable must be default-imported (and vice versa).

This is how you import something that was default-exported:

// maths.js
const a = 1;
export default a;

// index.js
import a from "./maths.js";
console.log(a); // 1;

Named-exports must be imported with curly brackets:

// maths.js
export const a = 1;
export const b = 2;

// index.js
import { a } from "./maths.js";
console.log(a); // 1;

You can import as many named-exports as you like on the same line:

import { a, b } from "./maths.js";
console.log(a, b); // 1 2

Import paths must be valid URIs. They can be local to your machine ("./maths.js") or on the web ("https://cdn.pika.dev/lower-case@^2.0.1"). This means you must include the file extension for local files. Node lets you ignore this, but it is mandatory in the browser.

Challenge

To get started download the starter files, cd into the directory, then run npx servor workshop to start a dev server. ES Modules require a server to work, so you can't just open the index.html file directly.

1. Split up the JS code in workshop/index.js into 3 files:

   • math.js containing the operator functions

   • calculate.js containing the calculate function

   • index.js containing the DOM event handlers

2. Change each file so they export and import everything they need to

3. Don't forget browsers only support imports inside a script tag with type="module"

Learn how to write your own Express middleware to do logging and authentication.

Middleware

Express is built around middleware. Middleware are functions that receive a request, do something with it, then either pass the request on to the next middleware or send a response (ending the chain).

Technically all route handlers are middleware, since they fit the above definition. However middleware usually transform the request in some way and don't actually send a response.

For example the built in express.urlencoded middleware grabs the HTTP request body, turns it into an object, then attaches it to the request object. This allows subsequent handlers to easily access it at request.body. The 3rd party cookie-parser middleware does the same for cookies. We're going to learn how to create our own middleware functions.

Setup

1. Download the starter files and cd in

2. Run npm install to install all the dependencies

3. Run npm run dev to start the development server

Visit http://localhost:3000 to see the workshop app. You can "log in" by entering an email, which will be saved as a cookie so the server can identify you.

Our first middleware

It would be useful if our server logged each incoming request to our terminal. That way we can see a log of what's happening as we use our server locally.

Usually we match our handlers to specific routes (e.g. server.get("/about", ...). However we can run a handler for every route by using server.use:

server.use((req, res) => {
  console.log(`${req.method} ${req.url}`);
});

This will log the method and URL for every request the server receives (e.g. GET / or POST /submit). Unfortunately that's all it will do, as this handler never tells the next handler in the chain to run. This will cause all requests to time out, since the server never sends a response using response.send.

We can fix this with the third argument all handlers receive: next. This is a function you call inside a handler when you want Express to move on to the next one.

server.use((req, res, next) => {
  console.log(`${req.method} ${req.url}`);
  next();
});

This tells Express to run the logger handler before every request, then move on to whatever handler is queued for that route. E.g. if the user requests the home page (GET /) this handler will run, log the method/URL, then pass on to the next handler that matches GET /, which will send an HTML response.

Authentication middleware

Note: we are just storing all the session info about the user in an object in-memory. In a real app you'd want this to live in a persistent store like a database.

Accessing the user

Currently we are accessing the user cookie in three handlers (GET /, GET /profile and GET /profile/settings). We have to grab the session ID from the signed cookies, then look the session info up in the sessions object. This ends up being quite a lot of code repeated whenever we want to find out info about which user is currently logged in. We can create a middleware to handle this repeated task.

We don't know which routes will want to access the logged in user value so we'll set this middleware on the whole app using server.use. We'll mimic the other middleware we're using and add the user value to the req object. This lets us pass values down through the request chain to later handlers.

Challenge 1.1

1. Create a new middleware that runs before every request.

2. It should read the sid cookie and find the session info in the sessions object

3. Then create a "session" property on the request object containing that info

4. Finally call the next function to tell Express to move on to the next handler.

5. Change each handler that currently gets the session cookie to instead grab the info from req.session.

server.use((req, res, next) => {
  const sid = req.signedCookies.sid;
  const sessionInfo = sessions[sid];
  if (sessionInfo) {
    req.session = sessionInfo;
  }
  next();
});

server.get("/", (req, res) => {
  const user = req.session;
  // ...
});

server.get("/profile", (req, res) => {
  const user = req.session;
  // ...
});

server.get("/profile/settings", (req, res) => {
  const user = req.session;
  // ...
});

Protecting routes

Currently our GET /profile route is broken. If the user isn't logged in we get an error trying to access user.email (since req.session is undefined). It would be better to show a "Please log in" page for unauthenticated users.

Challenge 1.2

1. Amend the GET /profile handler to check whether there is a session.

2. If not send a 401 HTML response with an error message in the h1 and a link to the /log-in page.

server.get("/profile", (req, res) => {
  const user = req.session;
  if (!user) {
    res.status(401).send(`
      <h1>Please log in to view this page</h1>
      <a href="/log-in">Log in</a>
    `);
  } else {
    res.send(`<h1>Hello ${user.email}</h1>`);
  }
});

Now you should see the "please log in" page if you visit /profile when you aren't logged in. However the GET /profile/settings route has the same problem.

We could copy paste the above code, but it would be better to avoid the duplication and move this logic into a middleware that makes sure users are logged in.

Challenge 1.3

1. Create a new middleware function named checkAuth that takes req, res and next as arguments.

2. If there is no req.session respond with the 401 HTML.

3. If there is a req.session call next to move on to the next handler.

4. Add this middleware in front of the handler for any route we want to protect. We don't want this middleware running on all routes, since some of them are public.

Hint: you can set multiple middleware/handlers for a route by passing multiple arguments.

server.get("/example", doSomething, anotherHandler, (req, res) => {
  // ...
});

function checkAuth(req, res, next) {
  const user = req.session;
  if (!user) {
    res.status(401).send(`
      <h1>Please log in to view this page</h1>
      <a href="/log-in">Log in</a>
    `);
  } else {
    next();
  }
}

server.get("/profile", checkAuth, (req, res) => {
  // ...
});

server.get("/profile/settings", checkAuth, (req, res) => {
  // ...
});

In JavaScript functions are treated like any other variable. This concept is sometimes referred to as “first-class functions”. It lets us use functions in some interesting ways, and helps us manage "asynchronous" code.

Functions are variables

When you create a function in JS you are creating a normal variable:

function returnsOne() {
  return 1;
}

This code creates a new variable named returnsOne.

This is still true (and maybe more obvious) for arrow functions:

const returnsOne = () => 1;

This code also creates a new variable named returnsOne. Notice how this is similar to defining a different type of variable:

const num = 1;

You can reference this variable the same way you would any other (by using its name):

console.log(returnsOne);
// logs something like: `function returnsOne()`

Since functions are normal variables you can even pass them as arguments to other functions.

Mini-challenge 1

Lets try passing a function as an argument to another function. Since we're just playing around to see what happens we can write this code in the console on this page. Open up the console and try this:

1. Write a function named logger

2. It should take one argument, then log that argument

3. Call logger with the returnsOne function as an argument

What does the browser print?

Functions are callable

The main distinction between a function and other types of variable is that you can call a function. You call a function by putting parentheses (round brackets) after it:

returnsOne();

Calling a function will run the lines of code inside of it. This is useful for two reasons:

1. Functions let us reuse code without copy/pasting it.

2. Functions let us delay running code until we're ready.

Returning values

Functions need to be able to talk to each other. This is how you create a more complex program. You compose together a bunch of functions, passing the output of one into another.

The return keyword lets us control what value we get after calling a function. Our returnsOne function always returns a value of 1. When you call a function the lines of code inside are run, and the function spits out its return value in place. You can then use this returned value however you like.

You can save it as a new variable:

const answer = returnsOne();
console.log(answer);
// This will log `1`

Here you can imagine that returnsOne() replaces itself with its return value. It's the same as if we'd written const answer = 1 directly.

You can also use the called function directly without an intermediary variable:

console.log(returnsOne());
// This will also log `1`

Here the same thing happens. returnsOne() replaces itself with its return value. It's the same as if we'd written console.log(1) directly.

If the function doesn't have a return statement you'll get undefined:

function returnsNothing() {
  const x = 3 + 5;
  // doesn't have a return statement
  // the x variable is basically thrown away
}
const answer = returnsNothing();
console.log(answer);
// This will log `undefined`

Calling or not calling a function is often a source of confusion when passing functions as arguments to other functions.

Mini-challenge 2

1. Open your console and recreate your logger function from above

2. Call logger, but this time pass in returnsOne() (don't forget the parentheses)

3. Why do we see a different value logged than before?

4. Edit logger to log the type of the value using the typeof operator

Inline functions

You can also define functions inline: i.e. directly as you're using them. This is a common pattern for passing functions as arguments to other functions. For example we could re-write our logger example:

logger(function () {
  return 1;
});

Here we're defining a new function inline at the same time that we're passing it to logger. This is a little hard to read, which is why most developers use arrow functions for inline functions like this:

logger(() => 1);

This has the same result as before, when we defined a separate returnsOne variable and passed it by name. The main difference here is we can't re-use the function, since it only exists as an argument to logger.

Mini-challenge 3

Inline functions are often used for event listeners in the DOM. For example this code will log wherever the user clicks on the window:

window.addEventListener("click", (event) => {
  console.log(event.clientX, event.clientY);
});

1. Open your console and enter the event listener above

2. Extract the inline function and assign it to a named variable

3. Pass your extracted function variable to addEventListener instead

The event listener should work the same whether your function is inlined or defined as a separate variable.

Callbacks

"Callback" is a scary word, but you've actually been using them the whole time. A callback is a function passed to another function as an argument. The name refers to what callbacks are usually used for: "calling you back" with a value when it's ready.

For example the addEventListener above takes a function that it will call when the "click" event happens. We're telling the browser "hey, call us back with the event info when that event happens".

Functions are a way to delay a block of code. Without them all our statements would run in order all in one go, and we'd never be able to wait for anything or react to user input.

Mini-challenge 4

1. Write a function named one that takes a function as a parameter

2. It should call that function with 1

3. Call your one function and pass in a function that logs its argument

Asynchronous callbacks

The callback above might feel a bit convoluted: why pass in a callback to access a variable from inside when we could make the one function return 1 directly?

Callbacks make more sense when dealing with asynchronous code. Sometimes we don't have a value to return straight away.

What is "asynchronous" code?

JavaScript is a "single-threaded" language. This means things generally happen one at a time, in the order you wrote the code.

console.log(1);
console.log(2);
console.log(3);
// This logs 1, then 2, then 3

When something needs to happen out of this order, we call it "asynchronous" ("async" for short). JavaScript handles this using a "queue". Anything async gets pushed out of the main running order and into the queue. Once JS finishes what it was doing it moves on to the first thing in the queue.

console.log(1);
window.setTimeout(() => console.log(2), 1000);
console.log(3);
// This logs 1, then 3, then (after about 1 second) logs 2

setTimeout is a built-in function that lets you run some code after a specified wait time.

It's intuitive that the above example logs 2 last, because JS has to wait a whole second before running the function passed to setTimeout.

What's less intuitive is that the order is the same even with a timeout of 0ms.

console.log(1);
window.setTimeout(() => console.log(2), 0);
console.log(3);
// This logs 1, then 3, then (as soon as possible) logs 2

This is because setTimeout always gets pushed to the back of the queue—the specified wait time just tells JS the minimum time that has to pass before that code is allowed to run.

How do callbacks help?

Callbacks let us access values that may not be ready yet. Imagine ordering food in a takeaway. If you just get a pre-packaged sandwich they might be able to hand it to you straight away. This is "synchronous"—they can give you what you need then move on to the next person in the queue.

However if your food needs to be cooked you might give them your phone number, so they can text you when it's ready. This is "asynchronous"—they can move on to the next person in the queue, and "call you back" to collect your food later.

Our addEventListener example from above can't return the click event, since it hasn't happened yet. The browser won't know where the user clicked until the click happens. So instead we pass a callback that the browser will run for us when the user clicks somewhere. It calls this callback with the event object containing the info we need.

Mini-challenge 5

1. Write a function asyncDouble that takes 2 arguments: a number and a callback

2. It should use setTimeout to wait one second

3. Then it should call the callback argument with the number argument multiplied by 2

4. Call asyncDouble with 10 and a callback that logs whatever it is passed. You should see 20 logged after 1 second.

5. Can you see why asyncDouble can't just return the doubled value?

Workshop

Let's use callbacks to make some traffic lights. Download the starter files using the command at the top of this workshop. Open challenge/index.html in your editor.

1. Inside the script tag write a function light that takes two parameters: a string and a callback

2. It should wait 1 second, log the string and then call its callback parameter

3. Use light to log each colour of a traffic light sequence, in order, followed by "finished"

   • e.g. It should log:

   Copy

   green
   amber
   red
   amber
   green
   finished

   with a 1 second pause before each colour

Stretch

Now we have a nested function that logs our traffic lights. However, highly nested functions can be hard to read. We can mitigate this by using a loop. Open challenge/stretch/index.html in your editor.

1. Define an array, light_sequence containing each colour of the light sequence, ending with "finished"

2. Modify your light function to include a third delay parameter and pass it to your setTimeout function

3. Use a method such as forEach on light_sequence to pass each element of the array to the light function

4. Start by calling the light function with a 1 second pause. What do you notice?

5. Try and replicate the behaviour of the previous function exactly. How can you ensure the delay is kept between the log of each colour?

It's important to remember that the web is for everybody. You should strive to build interfaces that are accessible to as many people as possible. This means specifically including users who often get left out: those with disabilities.

As developers we have both a moral and legal imperative to make sure our applications are accessible. A UI that can only be used by a sighted person with a mouse should be considered broken, just like a UI that isn't usable with a mouse would be considered broken.

This workshop will cover some of the ways disabled users browse the web, how to design/develop to meet those needs, and how to test your code to make sure that it does.

Key points

• Don't make assumptions about how people will use your site

• Strive to make your UI usable by everyone

• Get out of your comfort zone when testing your UI

Common problems

It's easy for developers to forget that people using their apps aren't necessarily like them. This can include both permanent disabilities, temporary disabilities, and even unavoidable technical limitations.

Here are some examples:

• A colorblind user cannot perceive the difference between certain colours. If you use only colour to indicate what a button does they won't be able to use it.

• A blind user cannot see your UI, and may use screen reader software to have the elements on the page read out loud by their computer. If you only communicate important information visually (e.g. using images) they won't hear it.

• A user with a broken arm in a sling cannot use their mouse. If your UI doesn't allow them to navigate with their keyboard they won't be able to use it.

• A low-income user may not have the latest iPhone. If your app only works properly on fast, new, expensive devices you are excluding them.

This document will mostly focus on keyboard and screen reader access, since those tend to be the predominant problems for web developers to solve. However that does not mean other disabilities are not important to consider when designing and developing interfaces.

Different ways to navigate

If you're a non-disabled web developer it's possible you aren't aware of or haven't tried navigating the web using anything but your mouse. It's important to get a sense of how other people will be attempting to use the sites you build.

Keyboard navigation

Many users cannot use a mouse, or find it easier to use their keyboard to navigate. This also applies to some visually-impaired users who will struggle to use a mouse if they cannot see the cursor.

You can scroll a web page up or down by pressing the up ↑ or down ↓ arrow keys. You can jump a whole "page" (equal to the viewport height) down with the spacebar.

You can also jump a page up or down using the Page Up or Page Down keys. On Mac keyboards without these keys you can use ⎇ option + ↑ or ↓.

You can scroll right to the top or bottom of a page using the Home or End keys. On Mac keyboards without these keys you can use ⌘ command + ↑ or ↓.

The most important key is "tab" ⇥. This will move your "focus" to the next interactive element on the page. For example links, buttons or inputs. This allows you to quickly jump between these elements, e.g. to fill out a form.

By default a "focused" element has an outline around it (in Chrome this is like a blue glow). You can "click" a focused button or link with the "return" ⮐ or spacebar keys. You can submit a form by pressing return whilst focusing an input.

Try using only your keyboard to navigate while you're reading the rest of this page.

Screen readers

Navigating via keyboard still requires you to know what content is on the page. Visually-impaired and blind people use "screen reader" software to read whatever is on the page out loud.

Most operating systems have a built-in screen reader now. macOS has VoiceOver, Windows 10 has Narrator and Linux has Orca.

Expand the relevant section below to get instructions for your operating system. Once you've got your screen reader working try to use it to navigate this page. It takes a bit of practice to get used to.

VoiceOver (macOS) You can activate Voiceover by pressing ⌘ command + F5 (or opening System Preferences and navigating to Accessibility > VoiceOver > Enable VoiceOver). By default VoiceOver shortcuts use the ∧ control and ⌥ option keys as a modifier. This is referred to as the "VO key" in [the docs](https://www.apple.com/voiceover/info/guide/_1121.html). Useful commands: - control: stop VoiceOver speaking at any time. - control + option + U: open the "Web rotor". Press ← or → to view all the headings/links/form controls etc on a page. - control + option + ← or →: move cursor to previous/next item. - Read more about [the basics of navigating with VO](https://www.apple.com/voiceover/info/guide/_1124.html)

Narrator (Windows 10) You can activate Narrator by pressing the Windows logo key + control + ⮐. By default Narrator keyboard shortcuts use caps lock ⇪ as the modifier key. This is labelled the "Narrator" key in [their docs](https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1). Useful commands: - control: stop Narrator speaking at any time. - ⇪ + S: read a summary of a webpage, including links and headings - ⇪ + ↓: start reading the document from the beginning - There are [lots of different ways to read text](https://support.microsoft.com/en-us/windows/chapter-4-reading-text-8054c6cd-dccf-5070-e405-953f036e4a15) so try exploring them.

Orca (Linux) Depending on which Linux distro you're using you may need to install Orca: ```bash sudo apt install orca ``` You should be able to run the `orca` command in your terminal to start it. By default Orca keyboard shortcuts use caps lock ⇪ as the modifier key on laptops. Read more in [their docs](https://help.gnome.org/users/orca/stable/howto_keyboard_layout.html.en). Useful commands: - ⇪ + S: stop Orca speaking. - ⇪ + ;: read the entire document from the beginning - ← or →: read previous/next character - alt + shift + H: show a list of headings - H and shift + H: read next/previous heading - There are [lots of other ways to navigate](https://techblog.wikimedia.org/2020/07/02/an-orca-screen-reader-tutorial/) so try exploring them.

Combinations

It's important to bear in mind that people don't fall neatly into separate categories. For example lots of keyboard users still use their mouse too. Lots of keyboard users can see the page fine. 85% of blind people have some degree of light perception, and so they may still use visual cues, or their mouse.

Developers sometimes try to detect what "type" of user is on the page, so they can enable/disable certain things (e.g. only show focus outlines for keyboard users). This is almost always a bad idea—you cannot detect accurately, and even if you could it's better to provide as similar an experience as possible to all users.

Testing accessibility

Web accessibility (often abbreviated to "a11y") is governed by the Web Content Accessibility Guidelines (WCAG). This is a shared standard that includes different criteria you can check your site against.

WCAG is quite long and complex, so a quick way to test a site is to use The A11y Project's Checklist. This is a list of simple things you should do on every site you build.

The A11y Project Checklist

You can also use automated testing tools to catch some types of problems. Chrome comes with a "Lighthouse" tab in the Developer Tools. This can run different types of tests on a page, including "Accessibility". It will inform you of obvious failures like low colour contrast or missing image alt text. However it cannot catch more complex problems, like a custom component that cannot be controlled with the keyboard.

Most importantly you should manually test—use the page in different ways and see if you get stuck. Try to fill out a form using only your keyboard. Turn your screen reader on and see if critical information gets left out. This will help you catch broken interactions that automated tools cannot.

Challenge

You're going to be identifying and fixing a11y problems on this example page. The page contains 11 failures; try to find them all.

1. Re-read The A11y Project's Checklist before you start so you can identify obvious WCAG violations.

2. Don't forget to use Chrome's Lighthouse tab to find easy problems.

3. You'll have to manually test with your keyboard and screen reader to find some of the issues.

Node is often used to create HTTP servers for the web. It's a bit fiddly to do this with just the built-in modules, so we're going to use the Express library to help create our server.

HTTP recap

HyperText Transfer Protocol (HTTP) is a way for computers to exchange messages over the internet. The "client" computer will send a "request" (often via a web browser). E.g. if you visit https://google.com your browser sends a request like this:

GET / HTTP/1.1
host: google.com
accept: text/html

A "server" computer receives this request and sends a "response". E.g. Google's server would send a response like this:

HTTP/1.1 200 Ok
content-type: text/html

<!doctype html>
<html><body><h1>Welcome to Google</h1>...</body></html>

We're going to learn how to use Node to create an HTTP server that can respond to requests.

Workshop prep

1. Create a new directory

2. Move into that directory

3. Initialise the project to create a package.json

4. Install the Express library

5. Open your editor and create a server.js file

mkdir node-server-intro
cd node-server-intro
npm init -y
npm install express
code .

Follow along with each example in your own editor.

Creating a server

We can create a new server object using the express module:

const express = require("express");

const server = express();

Handling requests

Our server currently does nothing. We need to add a "route". This is a function that will be run whenever the server receives a request to a specific path.

The server object has methods representing all the HTTP verbs (GET, POST etc). These methods take two arguments: the path to match and a handler function.

const express = require("express");

const server = express();

server.get("/", (request, response) => {
  response.send("hello");
});

Here we tell the server to call our function for any HTTP GET requests to our home path.

The handler function will be passed two arguments: an object representing the incoming request, and an object representing the response that will eventually be sent.

We can use the send method of the response object to tell Express to send the response. Whatever argument we pass will be sent as the response body.

Starting the server

Our Node program has a functioning server, but that server isn't currently listening for requests. Servers need to connect to the internet and listen for incoming HTTP requests on via a "port".

A "port" is an entry/exit point on a computer to allow network connections (like an airport allows people in/out of a country). HTTP uses port 80 by default (and HTTPS uses 443), so you don't normally see them in URLs on the web. E.g. when you visit https://google.com you are really going to https://google.com:443.

When you're running a server locally in development it's common to use a random number like 3000 or 8080. You can access a port by adding it to a URL like this: http://localhost:3000.

We can tell our server to listen on a port like this:

const express = require("express");

const server = express();

server.get("/", (request, response) => {
  response.send("hello");
});

const PORT = 3000;

server.listen(PORT, () => console.log(`Listening on http://localhost:${PORT}`));

We use the listen method of the server object. This takes the port number to listen on, and an optional callback to run when it starts listening. This callback is a good place to log something so you know the server has started.

Now we can run the program in our terminal:

node server.js

The server will start and you should see "Server listening on http://localhost:3000" logged.

Important: The Node process will continue running until you tell it to stop by typing control + c in your terminal. Every time you change your code you must stop the old process and start a new one by running node server.js again.

Sending requests

Open http://localhost:3000 in your browser. This will send a GET request to your server. You should see the "hello" response on the page. It's helpful to open the network tab of the dev tools so you can see all the details of the request and response.

The response

HTTP responses need a few different things:

1. A status code (e.g. 200 for success or 404 for not found)

2. Headers to provide info about the response

3. A body (the response data itself)

Status code

We're currently only providing the body. Express will set the status code to 200 by default. To set a different code use the response.status method:

server.get("/", (request, response) => {
  response.status(404);
  response.send("hello");
});

You can chain this together with send to make it shorter:

response.status(404).send("hello");

Headers

Express will automatically set some headers describing the response. For example since we called send with a string it will set the content-type to text/html and the content-length to the size of the string.

You can set your own headers using the response.set method. This can take two strings to set a single header:

response.set("x-fake-header", "my-value");

Or it can take an object of string values to set multiple headers:

response.set({
  "x-fake-header": "my value",
  "x-another-header": "another value",
});

HTML body

We aren't limited to plaintext in our body. The browser will parse any HTML tags and render them on the page. Change your handler to return some HTML instead:

server.get("/", (request, response) => {
  response.send("<h1>Hello</h1>");
});

Visit http://localhost:3000 again and you should see an h1 rendered.

Since we're rendering HTML using strings we can insert dynamic values using template literals. Let's add the current time to the response:

server.get("/", (request, response) => {
  const time = new Date().toLocaleTimeString();
  response.send(`<h1>Hello, it's ${time}</h1>`);
});

JSON body

We aren't limited to a text response. Lets send some JSON as well. Add a new route to your server:

server.get("/json", (request, response) => {
  response.send({ message: "Hello" });
});

HTTP response bodies are always strings, so Express will automatically convert our object to a JSON string for us. It will also set the content-type header to application/json.

Visit http://localhost:3000/json and you should see a JSON object with a message property.

Redirects

Sometimes we want to redirect the request to another URL. You can use the response.redirect method for this. Add a new route:

server.get("/redirects", (request, response) => {
  response.redirect("/");
});

Now if you visit http://localhost:3000/redirects in your browser you should end up back on the home page. If you look at the network tab in the dev tools you'll see two requests.

First a request to /redirects. This has a response status code of 302 and a location header pointing to /. This tells the browser to then make a second request to /.

Dynamic route paths

Sometimes you can't know in advance all the routes you need. For example if you wanted a page for each user profile: /users/oli, /users/dan etc. You can't statically list every possible route here. Instead you can use a placeholder value in the path to indicate that part of it is variable:

server.get("/users/:name", (request, response) => {
  const name = request.params.name;
  response.send(`<h1>Hello ${name}</h1>`);
});

We use a colon (:) to indicate to Express that any value can match a part of the path. It will put any matched values on the request.params object so you can use them.

If you visit http://localhost:3000/users/oli you should see "Hello oli". If you visit http://localhost:3000/users/knadkmnaf you should see "Hello knadkmnaf".

Missing routes

Try visiting http://localhost:3000/not-real in your browser. You should see Cannot GET /not-real. This is Express' default response for when no handler matches a path.

You can customise this by putting a "catch-all" handler after all your other routes. If no other route matches then this will be used (since Express matches them in the order they are defined).

We can use the server.use method to create a handler that will match any method/route:

server.use((request, response) => {
  response.status(404).send("<h1>Not found</h1>");
});

Reload http://localhost:3000/not-real and you should now see your custom response.

Middleware

Express route handlers don't have to send a response. They actually receive a third argument: the next function. Calling this function tells Express to move on to the next handler registered for the route.

Let's add another handler for the home route. It will just log the request, then move on to the next handler:

server.get("/", (request, response, next) => {
  console.log(request.method + " " + request.url);
  next();
});

server.get("/", (request, response) => {
  response.send("<h1>Hello</h1>");
});

If you run this code and refresh the home page you should see GET / logged in your terminal.

The route methods accept multiple handler functions, so you can actually pass them all in one go. This does the same thing:

function logger(request, response, next) {
  console.log(request.method + " " + request.url);
  next();
}

server.get("/", logger, (request, response) => {
  response.send("<h1>Hello</h1>");
});

Express calls handlers that don't send a response "middleware". Our example here isn't that useful, but we could change it to run before all requests. We can do this with server.use:

server.use(logger);

Now we'll get a helpful log like GET / in our terminal when we load any page. Without middleware we would have to copy this into every route we wrote.

Static files

It's common to have some static files that don't change for each request. E.g. CSS, images, maybe some basic HTML pages. For convenience Express includes a built-in middleware for serving a directory of files: express.static.

Create a new directory named public. This is where we'll keep all the files sent to the client. Create a public/style.css file with some example CSS.

Finally configure the middleware to serve this directory:

const staticHandler = express.static("public");

server.use(staticHandler);

The server will now handle requests to http://localhost:3000/style.css and respond with the file contents. Note that there is no public in the final URL: Express serves the files from the root of the site.

Post requests

So far we've only created GET handlers. Let's add a POST handler to see how we'd deal with forms submitting user data to our server:

server.post("/submit", (request, response) => {
  console.log("posted");
  response.send("thanks for submitting");
});

We can't make a test POST request as easily in our browser, since that would require a form. Instead we can send a request from our terminal using the curl program.

Open a new terminal window/tab and run:

curl -X POST localhost:3000/submit

You should receive a response of "Thanks for submitting". You can add the --verbose flag to see the entire HTTP request/response. If you check the terminal where your server is running you should see "posted" logged.

Request body

A POST request that doesn't send any data isn't very useful. Usually a form would be submitting some user input. We can add data to our curl request with the -d flag:

curl -X POST localhost:3000/submit -d "name=oli"

However since bodies can be large they come in lots of small chunks. This means there's no simple way to just access the body. Instead we must use a "body parser" middleware.

For convenience these are included as part of the Express module. Request bodies can come in different formats (JSON, form etc), so we must use the right middleware. We want express.urlencoded, which is what forms submit by default. This is a function we call to create our middleware:

const bodyParser = express.urlencoded();

server.post("/submit", bodyParser, (request, response) => {
  console.log(request.body);
  response.send("thanks for submitting");
});

This middleware will wait until all the submitted data has been received, then add a body property to the request object. We can then read this property in our handler.

If you use curl to send another POST request you should see something like { name: 'oli' } logged in your server terminal.

That's it, you've learnt the basics of using Node and Express to create an HTTP server.

This workshop will help you practise with Git on the terminal. Follow these steps to connect a local repository to a remote one on GitHub. Before following these steps, you'll need to .

This workshop is an advancement on concepts covered in . Completing that workshop is not a requirement to understand this one, however you might prefer to focus on the fundamentals there before diving into this workshop.

This workshop assumes you have a working knowledge of .

Getting started

Create a folder on your computer and give it a name relevant to your project. Your local folder should share a name with the repository you create on GitHub.

Open up your terminal and navigate to the folder where you've saved your files.

Initialise this folder as a Git repository. You can do this by running the command git init.

Add files for HTML, CSS and JavaScript. Add some content to the HTML, link the CSS and add a script tag which points to your JS file.

Staging

Staging defines which files we'd like to add to our next commit. When staging, you can specify files to stage, or using the . you can stage all the files in your current directory.

To stage our index.html only:

git add index.html

To stage all files in the directory:

git add .

Committing

Committing is like saving your progress at a point in time. You are telling Git that all the changes staged should be tracked.

git commit

The -m flag allows you to write a commit message in the command line.

git commit -m "Create HTML, CSS and JavaScript files"

It's conventional to use the imperative verb - for example "change this" rather than "changing this".

Aim for your commit history to describe precisely and concisely what you did in that change. Someone reading your commit history should be able to identify at a glance what changes were made.

Remote repository

Create a new repository on GitHub. You can do so by navigating to your repositories and clicking the green 'new' button.

The easiest way to set this up is without a README to avoid conflicts in the Git history. When you land on the repository page, Git will give you commands for connecting your local repository to the remote; renaming your main branch; and pushing your changes.

git remote add origin <url>
git branch -M main
git push -u origin main

First, you're pointing Git to the url of your remote repository.

The -u flag here will set the default remote branch so when you make your next push, you'll only need to type git push. You can batch multiple commits and push them all together.

Host your site

Deploy your site to GitHub Pages in the repository settings. You'll receive a link to the live version of your site.

Add this url to your README.md and repository description.

It can take a few minutes for GitHub to deploy the repository for the first time. You might need to wait a little while before you see your changes live.

Making changes

Once you have a local and remote repository connected, you'll be able to keep both in sync by regularly staging, committing and pushing your changes to GitHub.

You should commit once you have completed a change or feature, not after writing certain amount of code, and don't wait until a project is complete. Getting into the habit of making small commits often will give you a good level of practice with Git. Regularly pushing your changes will ensure your codebase is backed up and version-controlled. Additonally, you'll have GitHub activity on your profile (green squares).

Once you have a local and remote repository connected, keep them in sync by regularly staging, committing and pushing your changes.

After you've saved your changes, stage them using git add.

Commit your staged files using git commit -m "What you did...".

Push your changes to your repository using git push.

This workshop will guide you through the process of setting up and using GitHub Projects for effective project management and collaboration. You'll learn how to create a project, add tasks, link them to issues, and use different views to track progress.

Part 1: Understanding GitHub Projects

Step 1: What is GitHub Projects?

Despite its name, GitHub Projects is not tied to a single repository. It's a project management tool that can be used across multiple repositories or even without any repository at all.

1. GitHub Projects is a flexible tool for planning and tracking work.

2. It can be used for various purposes, from software development to event planning.

3. Projects are not automatically tied to repositories when created.

Step 2: Creating a GitHub Project

1. Go to your GitHub profile or organization.

2. Click on "Projects" in the top navigation bar.

3. Click "New project".

4. Choose a template or start from scratch.

5. Give your project a name and description.

Step 3: Managing Access

Like repositories, GitHub Projects can be public or private, and you need to manage access to them.

1. Go to your newly created project.

2. Click on the three dots (...) menu in the top right corner.

3. Select "Settings".

4. Go to "Manage access".

5. Add collaborators as needed.

Part 2: Working with GitHub Projects

Step 1: Exploring Different Views

GitHub Projects offers different views to help you visualize your work:

1. Board view: A Kanban-style board for task management.

2. Table view: A spreadsheet-like view for detailed tracking.

3. Roadmap view: A Gantt chart for timeline visualization.

Let's explore each of these:

1. In your project, click on the dropdown next to the current view name (likely "Board").

2. Select each view and observe how the information is presented differently.

Step 2: Creating Tasks (Tickets)

In the Board view:

1. Click the "+ Add item" button at the bottom of a column.

2. Type a title for your task.

3. Press Enter to create the task.

Step 3: Converting Tasks to Issues

Converting a task to an issue allows for better traceability and automation.

Method 1: From the task detail

1. Click on a task to open its details.

2. Click on the "Convert to issue" button.

3. Select the repository where you want to create the issue.

4. Click "Create issue".

Method 2: Using the three dots menu

1. Click on the three dots (...) menu next to the task.

2. Select "Convert to issue" from the dropdown menu.

Step 4: Assigning Tasks

1. Click on a task to open its details.

2. In the sidebar, click on "Assignees".

3. Select the team member you want to assign the task to.

Step 5: Using the Roadmap View

The Roadmap view helps in setting deadlines and visualizing the project timeline.

1. Switch to the Roadmap view.

2. Click and drag on a task to set its start and end dates.

3. Observe how tasks are arranged on the timeline.

Part 3: Integrating with Repositories

Step 1: Linking a Project to a Repository

1. Go to your repository on GitHub.

2. Click on the "Projects" tab.

3. Click "Link a project".

4. Select your project from the list.

Repeat these steps for each repository you want to link to the project. This allows you to:

• Track issues and pull requests from multiple repositories in one place

• Create cross-repository dependencies

• Get a holistic view of your entire project, even when the code is distributed across different repositories

Remember, you can link as many repositories as needed to a single project, making it easier to manage large, multi-component software projects.

Step 2: Managing Workflows

GitHub Projects allows you to manage automation workflows based on repository activity.

1. In your project, go to "Settings" > "Workflows".

2. You'll see a list of predefined workflows that you can enable or disable.

3. To adjust a workflow, click on it to edit its settings. For example, make sure the workflow "When an issue is closed, set its status to Done" is enabled. (Note: This workflow may already be enabled by default in some project templates).

You don't want your deployed production app talking to a database running on your laptop. This would be slow, insecure and require you to leave it turned on all the time.

Instead we can host our production database on a 3rd party service like Heroku. This is especially convenient if we're already hosting our production server on Heroku.

Follow these .

Once you're done you should have a connection string that looks something like this:

postgres://okaws:d3fa@ec2-54.eu-west-1.compute.amazonaws.com:5432/d8bvo

You can connect to the remote database from your terminal by running:

psql your_url_goes_here

Advanced SQL

Let's practice some more advanced SQL commands. There's a bunch of data about various FAC cohorts in init.sql. You'll need to read this to figure out exactly what tables you're working with.

You may have to search the internet for SQL you haven't seen before. is a good resource.

There's usually more than one way to get the right answer. If your solution is different that's fine!

Setup

1. Download the starter files

2. Connect to your Heroku database with psql your_database_url

3. Insert the data into your DB with \i init.sql

You can check everything is set up by listing the database tables with \dt. You should see four FAC-related tables: cohorts, students, projects and students_projects.

1. Cohort locations

   List the names of all cohorts that took place in Finsbury Park.

   Expected result
2. Student locations

   List the usernames of all students who attended FAC in Finsbury Park.

   Expected result
3. Student locations

   List the username of each student along with the location of their cohort.

   Expected result
4. Students with projects

   List all project names with the usernames of the students who worked on them.

   Expected result
5. Bonus: Students with projects by location

   List all project names with the usernames of the students who worked on them, only for students who attended FAC in Finsbury Park.

   Expected result

An exercise to practice git workflow skills. The workshop should be undertaken by two programmers, working on two computers.

Note: you may see references to a master branch in diagrams or external resources. This used to be the name of the default Git branch, but this was changed to main last year. New repos should all have a main branch, so that's what you should use.

Part 1: Initial setup

You're working in a team of two on a project for a new client. Steps 1 to 8 in this section should be completed by one of you, who we'll refer to as Programmer 1.

Step 1: make a new repo

Programmer 1 creates a new GitHub repo and clones it.

1. Create a new GitHub repo on Programmer 1's profile, making sure to initialise it with a README.md

2. Go to "Settings > Collaborators" and add Programmer 2 so they can access the repo

3. Programmer 2 should check their email and accept the invite to collaborate

4. Clone this new repository using your terminal.

   Copy

   git clone 'PASTE THE URL OF YOUR REPOSITORY HERE'

5. Move into the newly created directory.

   Copy

   cd your-repo-name-here

   This is what your remote and local repositories look like after this. HEAD is a reference to your current location.

Step 2: raise issues

Normally you would decide on which "features" you were going to build and then break these down into smaller tasks before starting the work. These tasks can be tracked with GitHub issues.

1. Raise a new issue with a descriptive title.

2. In the body of the issue, provide more detail about how to complete the work.

3. Assign yourselves to this issue.

Step 3: move to a new branch

1. Create a branch with a unique and descriptive name. For example, create-heading-with-shadow.

   Copy

   git branch create-heading-with-shadow
2. Leave the main branch by switching to the new branch you have just created.

   Copy

   git checkout create-heading-with-shadow

Alternatively you can do this in a single step by using the -b flag to tell the git checkout command to create the new branch:

git checkout -b create-heading-with-shadow

An easy way to check which branch you are working on is to look at the VS status bar. In the following example, the branch is 'FAC30_updates.'

By clicking on the branch name, you can view all branches, both local and remote (those that are in the repository but not on your local machine)."

This can be useful to get the big picture, but we highly recommend using the command line instead. The equivalent command to show all the branches is:

git branch -a."

Step 4: satisfy the requirements

Now we need to write some code to add the new feature.

1. Add the following code into a new file called index.html.

   Copy

   <!DOCTYPE html>
   <html lang="en">
     <head>
       <meta charset="UTF-8" />
       <meta name="viewport" content="width=device-width, initial-scale=1.0" />
       <link rel="stylesheet" href="style.css" />
       <title>Git Workflow Workshop</title>
     </head>
   
     <body>
       <h1 class="some-heading">GIT WORKFLOW WORKSHOW</h1>
     </body>
   </html>

   Note: you may notice errors in this code. This is deliberate—we'll be fixing them later on in the workshop.

2. Create a new file called style.css which contains:

   Copy

   * {
     margin: 0;
     padding: 0;
   }
   
   .page-heading {
     box-sizing: border-box;
     font-family: "Avant Garde", Avantgarde, "Century Gothic", CenturyGothic,
       "AppleGothic", sans-serif;
     font-size: 3.5rem;
     padding: 5rem 3rem;
     text-align: center;
     text-rendering: optimizeLegibility;
     color: #131313;
     background-color: #e7e5e4;
     letter-spacing: 0.15em;
     text-shadow: 1px -1px 0 #767676, -1px 2px 1px #737272, -2px 4px 1px #767474,
       -3px 6px 1px #787777, -4px 8px 1px #7b7a7a, -5px 10px 1px #7f7d7d,
       -6px 12px 1px #828181, -7px 14px 1px #868585, -8px 16px 1px #8b8a89, -9px
         18px 1px #8f8e8d, -10px 20px 1px #949392, -11px 22px 1px #999897,
       -12px 24px 1px #9e9c9c, -13px 26px 1px #a3a1a1, -14px 28px 1px #a8a6a6, -15px
         30px 1px #adabab, -16px 32px 1px #b2b1b0, -17px 34px 1px #b7b6b5,
       -18px 36px 1px #bcbbba, -19px 38px 1px #c1bfbf, -20px 40px 1px #c6c4c4, -21px
         42px 1px #cbc9c8, -22px 44px 1px #cfcdcd, -23px 46px 1px #d4d2d1,
       -24px 48px 1px #d8d6d5, -25px 50px 1px #dbdad9, -26px 52px 1px #dfdddc, -27px
         54px 1px #e2e0df, -28px 56px 1px #e4e3e2;
   }

Step 5: stage your changes

Staging changes in Git:

1. Add index.html and style.css to the staging area.

git add index.html style.css

If you know you definitely want to stage all your current changes you can save some typing and use:

git add .

Step 6: commit your changes

The message you type to describe each commit is important, since it will be preserved in the history of the project for future contributors. It should be descriptive and relatively high-level—someone can always read the code to find out specifically what you changed.

For example this message is not descriptive enough: "update title". This one is a bit too descriptive: "Use an h1 element with a classname applying nice text shadow CSS". This one has a good balance: "Add new page heading element with styles".

1. Commit the files that are in the staging area.

   Copy

   git commit -m 'Add new page heading element with styles' -m 'Relates #1'

One final note about committing: Take a moment to review your changes before confirming your commit. While unstaging changes is straightforward, there's no simple "uncommit" command. Although it's possible to undo a commit, it can be a complex process, especially if you've already pushed the commit to a shared repository. It's always better to carefully consider your commit before finalizing it.

Step 7: push your changes to GitHub

After committing your changes locally, your remote repository on GitHub remains unchanged. To synchronize your local changes with the remote repository, you need to push your changes.

1. Ensure you're on the correct branch: Before pushing, double-check that you're on the branch you want to push:

   Copy

   git branch

   This should show create-heading-with-shadow with an asterisk next to it.

2. Push the create-heading-with-shadow branch to the "origin": The "origin" refers to the GitHub repository that you originally cloned from. Use the following command:

   Copy

   git push origin create-heading-with-shadow

   This command tells Git to push your local create-heading-with-shadow branch to the same branch on the remote repository.

3. Check the push result: After pushing, Git will display a message indicating the result. If successful, it will show something like:

   Copy

   To https://github.com/your-username/your-repo.git
   * [new branch]      create-heading-with-shadow -> create-heading-with-shadow

4. Verify on GitHub: After pushing, visit your GitHub repository in a web browser. You should see your new branch listed, and it will contain the changes you just pushed.

Step 8: create a pull request

After pushing your changes to GitHub, the next step is to create a Pull Request (PR). A PR is a way to propose changes from a branch to the main codebase and request review from your teammates.

1. Navigate to the repository on GitHub:

   • Open your web browser and go to the GitHub page of your repository.

2. Initiate the Pull Request:

   • You should see a prompt suggesting to create a PR for your recently pushed branch. If not, click on the "Pull requests" tab, then click the "New pull request" button.

   • Select the branch you want to merge (in this case, create-heading-with-shadow) into the main branch.

3. Set up the Pull Request:

   3.1 Add a descriptive title:

   • Choose a clear, concise title that summarizes the changes (e.g., "Create page heading with shadow effect").

   • Good titles help reviewers quickly understand the purpose of the PR.

   3.2 Write a detailed description in the body:

   • Explain what changes you've made and why.

   • Mention any potential impacts or dependencies.

   • If applicable, include steps to test the changes.

   • Link the PR to the relevant issue:

     • Use keywords like "Relates #1" to reference the issue without closing it automatically.

     • Use "Closes #1" or "Fixes #1" if this PR should close the issue when merged.

   3.3 Select reviewers and assignees:

   • Assign Programmer 2 as the reviewer. They will be notified to review your changes.

   • You can also assign yourself or Programmer 2 to the PR, indicating who's responsible for moving it forward.

4. Preview and submit:

   • Review all the information you've added to ensure it's complete and accurate.

   • Click "Create pull request" to submit it.

5. Post-creation actions:

   • After creating the PR, you can still edit its description, add comments, or include additional commits to the branch.

   • GitHub will automatically run any configured checks or integrations.

Step 9: merge the pull request

You usually shouldn't merge your own pull requests. A PR gives the rest of your team the chance to review before your changes are merged into main. In your projects, you will be asking the other pair to do this.

1. Programmer 2 reviews the changes. This is where you'd leave any feedback or request changes to be made.

2. Programmer 2 merges the pull request

Now your remote repo looks like this:

After the pull request is merged, you should address the related issue: If you included "Closes #1" (or similar closing keywords) in your commit message or pull request description, GitHub will have automatically closed the associated issue. If not, you should manually close the issue that tracked this feature, as the work is now complete and merged into the main branch.

---https://github.com/foundersandcoders/coursebook.git

Part 2: splitting the work

Your quality assurance engineer has just noticed some problems with the recent change to the website.

1. Spelling mistake in the heading (the word 'WORKSHOW' should be replaced with 'WORKSHOP')

2. The classname applied to the h1 is wrong, so the styles aren't applying (class="some-heading" should be replaced with class="page-heading").

Programmer 1 will fix the first problem and Programmer 2 will fix the second. From this point on you both need to work on separate computers.

Note: Only one line in the index.html file needs to be modified.

Step 1: clone the repo (Programmer 2)

1. Programmer 2 also needs a copy of the repo, since they haven't worked on it yet

   Copy

   git clone 'PASTE THE URL OF YOUR REPOSITORY HERE'

Step 2: raise 2 new issues

1. Create the following two issues and assign each one to a different person

   • Fix typo in page heading (Programmer 1)

   • Correct the classname of page heading (Programmer 2)

Remember or take note of the issue numbers when you create them, as you will need these later on.

Step 3: create your branches

Git branches are used to make sure each person can work independently without affecting the code others in the team are working on.

1. Both programmers create one branch each:

   • git checkout -b fix-typo-heading (Programmer 1)

   • git checkout -b update-class-heading (Programmer 2).

Step 4: make your changes

It's important to avoid making unrelated changes as you work. It can be tempting to just quickly fix an error if you spot one while doing some other work. However this makes the Git history of changes really difficult to track. It's also confusing to review a pull request that has lots of unrelated changes.

1. Programmer 1 fixes only the spelling typo in the heading (WORKSHOW -> WORKSHOP).

   Copy

   <h1 class="some-heading">GIT WORKFLOW WORKSHOP</h1>

2. Programmer 2 updates only the class name of the heading (class="some-heading" -> class="page-heading").

   Copy

   <h1 class="page-heading">GIT WORKFLOW WORKSHOW</h1>

Step 5: stage your changes

1. Both programmers save their index.html files.

2. Both programmers check the status of their files, to confirm that index.html has been modified.

   Copy

   git status

3. Both programmers add their modified index.html file to the staging area.

   Copy

   git add index.html

Step 6: commit your changes

1. Both programmers should commit their changes. Remember to use a multi-line commit message that references the relevant issue. (Refer back to the issue numbers you noted when you created them.)

Important: don't work in parallel from here. We want to push, PR and merge Programmer 1's change first, then move on to Programmer 2's change.

Step 7: pull any new changes (Programmer 1)

Before pushing your branch, it's crucial to incorporate the latest changes from the remote main branch. In real-world projects, multiple team members often contribute code simultaneously, which can lead to divergence between your branch and the main codebase. To minimize conflicts and ensure your changes integrate smoothly:

1. First, always fetch and merge the latest updates from the remote main branch into your working branch.

2. Then, resolve any conflicts that may arise from this merge.

3. Only after successfully integrating the latest main changes should you push your branch.

Let's integrate this workflow in our workshop:

1. Programmer 1 switches to main branch.

   Copy

   git checkout main

2. Programmer 1 pulls any changes from the main branch of the remote (GitHub repo). There should be no changes since neither of you has pushed any changes yet.

   Copy

   git pull origin main

   On the default branch you can use a shorthand, since Git knows which remote branch to use:

   Copy

   git pull

3. Programmer 1 switches back to the fix-typo-heading branch.

   Copy

   git checkout fix-typo-heading

   Since there were no new changes to deal with Programmer 1 can move on to pushing.

Step 8: push changes (Programmer 1)

1. Programmer 1 pushes their fix-typo-heading branch to remote

   Copy

   git push origin fix-typo-heading

Step 9: create a pull request (Programmer 1)

1. Programmer 1 creates a pull request.

   • Don't forget a descriptive title/body (and link the relevant issue in the body)

   • Assign Programmer 2 to review

Step 10: review the pull request (Programmer 2)

1. Programmer 2 reviews the pull request

   1. Step through each commit (in this case one)

   2. Check the "Files changed" tab for a line-by-line breakdown.

   3. Click "Review changes" and choose from "Comment", "Approve" or "Request changes"

Step 11: merge the pull request (Programmer 2)

1. Programmer 2 merges the pull request

Note: now Programmer 1's changes are merged we can move on to Programmer 2's

Step 12: pull any new changes (Programmer 2)

Remember it's always a good idea to check for any new changes on the remote before pushing your branch. In this case we know that Programmer 1's branch was just merged, so there will be changes. Once we've pulled them to the local main branch we'll need to merge them into the update-class-heading branch.

1. Programmer 2 switches to main branch.

   Copy

   git checkout main

2. Programmer 2 pulls the remote main branch

   Copy

   git pull
3. Programmer 2 switches back to the update-class-heading branch.

   Copy

   git checkout update-class-heading

4. Programmer 2 tries to merge main branch into update-class-heading branch.

   Copy

   git merge main

   At this point there should be a "merge conflict". Move on to the next section to find out how to resolve this.

Step 13: resolve merge conflicts (Programmer 2)

<body>
  <<<<<<< HEAD
  <h1 class="page-heading">GIT WORKFLOW WORKSHOW</h1>
  =======
  <h1 class="some-heading">GIT WORKFLOW WORKSHOP</h1>
  >>>>>>> main
</body>

The code between <<<<<<< HEAD and ====== is the current change on this branch. The code between the ====== and >>>>>>> main is the change from the main branch that we are merging in.

You can resolve the conflict by manually editing the code to leave only the change you expect. You can also use VS Code's built-in options to choose either the HEAD or main change (or both). You also need to make sure to remove the conflict marker lines, since those are not valid HTML code. Finally you need to make a new commit for the merge.

1. Programmer 2 removes HEAD and main markers

2. Programmer 2 manually merges the two different h1 lines to keep both new changes

   Copy

   <body>
     <h1 class="page-heading">GIT WORKFLOW WORKSHOP</h1>
   </body>

3. Programmer 2 adds the index.html file to staging area and commits the merge changes.

git add index.html
git commit -m 'Merge main and resolve conflicts'

Step 14: push your changes (Programmer 2)

1. Programmer 2 pushes the update-class-heading branch to remote.

  git push origin update-class-heading

Step 15: create a pull request (Programmer 2)

1. Programmer 2 creates a pull request.

   • Don't forget a descriptive title/body (and link the relevant issue in the body)

   • Assign Programmer 1 to review

Step 16: review the pull request (Programmer 1)

1. Programmer 1 reviews the pull request

   1. Step through each commit (in this case one)

   2. Check the "Files changed" tab for a line-by-line breakdown.

   3. Click "Review changes" and choose from "Comment", "Approve" or "Request changes"

Step 17: merge the pull request (Programmer 1)

1. Programmer 1 merges the pull request

Finishing up

That's it, you have successfully followed the GitHub flow to add a new feature and fix some bugs.

Both Programmer 1 and Programmer 2 can switch back to the main branch and pull the remote changes. They should also both delete their other local branches since they are now merged. The final step should be to close any open issues (if the PRs didn't do this automatically).