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:

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:

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:

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:

Visit . 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:

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:

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.

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:

You should see an object like this logged:

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:

If you visit 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:

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:

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.

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.

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:

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

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.

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:

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

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:

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

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:

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".

The Cypress app showing a single test

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:

Cypress uses a global it function to define tests. This works just like the test function we wrote in the 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.

My browser running our first test

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:

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:

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.

A failed test in the sidebar

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

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:

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 . Here's a quick example with a few new ones that will useful:

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)

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

Stretch goal

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

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:

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:

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:

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

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:

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 /

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:

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

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:

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

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.

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:

And this is how you create a named export:

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

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

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:

Named-exports must be imported with curly brackets:

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

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

Functions are variables

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

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

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

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

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:

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.

If the function returns nothing you'll get 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` ```

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):

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

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.

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

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"

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.

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 install Git.

This workshop is an advancement on concepts covered in our Git introduction. 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 using the terminal.

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:

To stage all files in the directory:

Committing

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

Running the command without the -m flag will open up an editor in your terminal where you can write a commit message. Exit this by hitting esc and typing :wq. You can to avoid this.

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

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.

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

Second, you're renaming your branch to main. in 2020 to dissociate from using the term master which can have negative connotations.

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.

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

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.

For the sake of this exercise, we're just going to at the moment. Your client wants a beautifully styled heading for the homepage. It should be bold black writing with a background shadow that makes it stand out.

This is how the issues console looks on GitHub.

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

There are many types of workflow. At FAC we use , where the main branch is always deployable. In this flow, each branch is used for a separate feature.

1. Create a branch with a unique and descriptive name. For example, create-heading-with-shadow.

2. Leave the main branch by switching to the new branch you have just created.

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:

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:

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.

   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:

Step 5: stage your changes

Staging changes in Git:

Staging in Git is like a preparation area for your next commit. When you modify files in your project, you can choose which changes to "stage" using the git add command. These staged changes are what will be included in your next commit. This allows you to selectively commit only certain changes, even if you've modified multiple files. Think of it as a way to review and organize your changes before making them permanent in your project's history. For a more detailed explanation, you can refer to .

1. Add index.html and style.css to the staging area.

If you know you definitely want to stage all your current changes you can save some typing and use:

Step 6: commit your changes

The history of a project is made up of . Each commit is a snapshot of your whole repository at one particular time.

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".

Here are some on writing better, more useful commit messages.

It's also important to link your code changes to the issues that track them. GitHub lets you use a hash symbol followed by a number to . For example if the message includes Relates #1 it will show this commit in issue number 1 on the GitHub repo. If a commit totally fixes an issue you can use Closes #1, and GitHub will automatically close the issue when the commit is pushed to GitHub.

1. Commit the files that are in the staging area.

   Here we're using a second -m flag to add another line to our commit message with the extra issue info. You could also just run git commit, which will open your so you can write longer commit messages in a more comfortable environment.

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:

   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:

   This command tells Git to push your local create-heading-with-shadow branch to the same branch on the remote repository.

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:

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

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

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).

2. Programmer 2 updates only the class name of the heading (class="some-heading" -> class="page-heading").

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.

3. Both programmers add their modified index.html file to the staging area.

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.

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.

   On the default branch you can use a shorthand, since Git knows which remote branch to use:

Step 8: push changes (Programmer 1)

1. Programmer 1 pushes their fix-typo-heading branch to remote

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.

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.

2. Programmer 2 pulls the remote main branch

Step 13: resolve merge conflicts (Programmer 2)

This conflict occurred because the line with the <h1> heading was changed by Programmer 1 and Programmer 2. Git doesn't know how to merge the two different versions of this line together, so it needs you to do it manually. Merge conflicts are like this:

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

3. Programmer 2 adds the index.html file to staging area and commits the merge changes.

Step 14: push your changes (Programmer 2)

1. Programmer 2 pushes the update-class-heading branch to remote.

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.

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).

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.

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. , 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 (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 . 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.

Screenshot of a Lighthouse audit of this website

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 . The page contains 11 failures; try to find them all.

1. Re-read 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:

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

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

Follow along with each example in your own editor.

Creating a server

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

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.

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:

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:

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:

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

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:

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

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:

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:

JSON body

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

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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 covers how to connect your Node server to a Postgres database using the node-postgres library.

Setup

Before you begin make sure you have installed Postgres.

1. Download the starter files

2. cd into the directory

3. Run npm install

The starter files include some dependencies and database setup. As you work through the workshop you should read the corresponding files and try to understand what the code does. Each file includes explanatory comments to help.

Database setup

In order to run our app locally we'll need a Postgres database running on our machine to connect to.

Creating a local database

You can create a new Postgres user and a new Postgres database owned by that user with these two commands:

If this succeeds you shouldn't see any output in your terminal. You can check it worked properly by listing your databases with this command:

You should see the new learn_pg database in the list, like this:

Populating the database

You can list all the tables in your new database with this command:

You should see "Did not find any relations." This is because our database is empty—we haven't created any tables or inserted any data.

You can populate your database by running SQL commands to create tables and insert data. Doing this manually would be slow and repetitive, however you can run them from a file in the repo instead:

The /database/init.sql file contains SQL commands to create the tables we want, then insert some example data. You can re-run this command to wipe your DB and start from scratch whenever you need to.

This is dangerous. If you run this on your production database you'll delete all your data.

Connecting to the database

We can query our DB manually from the terminal using psql, but that doesn't help us build an app. We need a way for our Node server to connect to the DB. To do this we use the library. You need to install this into the project with:

Our app needs to know the database's address. Postgres runs a local server so you can talk to the DB. The full URL (also known as the "connection string") for your database will be:

You could hard-code this URL into our app code, but this address is only correct for the database running on your computer. When someone else clones your repo they'll have their own DB set up.

Environment variables

It's best to read configuration like this from an "environment variable" (env vars). This is like a JS variable, but set in your terminal before a program runs. You can set them before you start your application, like this PORT=3000 node server.js. You server can then read this value to know what port your app should listen on.

Take a look at the /database/connection.js file. It imports the pg library, then connects to the right DB by passing in the connection string. It reads this from the DATABASE_URL env var, which means we must make sure this is set before starting our server.

Rather than type DATABASE_URL=postgres://... npm run dev every time, we can rely on the popular dotenv library. This allows us to define env vars in a file named .env. We gitignore this file so each person who clones the repo can make their own with their own personal DB URL.

First install dotenv as a dev dependency:

Then create a .env file at the root of your project containing:

Then change your dev npm script in the package.json file to this:

The -r dotenv/config bit tells the dotenv library to read the .env file and pass all the values inside it to your application. You can then access them in your JS code with process.env.VAR_NAME.

Using the database

Now our server knows how to talk to our database we can start using it in our route handlers. First let's make our home route list all the users in the database.

Open workshop/routes/home.js. To access our DB we need to import the pool object we created in connection.js:

Querying for data

This db object has a .query method that sends SQL commands to the database. It takes a SQL string as the first argument and returns a promise. This promise resolves when the query result is ready.

Let's get all the users in the DB:

Refresh the home page and you should see a big object logged in your terminal. This is the entire result of our database query.

The bit we're actually interested in is the rows property. This is an array of each matching entry in the table we're selecting from. Each row is represented as an object, with a key/value property for each column.

You should see an array of user objects, where each object looks like this:

Since DB queries return promises we need to make sure we send our response inside the .then callback. Let's send back a list of all users' first names:

Refresh the page and you should see an unordered list containing each user's first name.

Challenge

We're currently querying for too much data: we only need the username, but we're getting every column. For very big data sets this could be a performance problem.

Amend your query so it only returns the column we need.

Updating data

Navigate to http://localhost:3000/create-user. You should see a form with fields for each column in our user database table. It submits a POST request to the same path. The post handler logs whatever data was submitted. Try it now to see it working.

We want to use the INSERT INTO SQL command to create a new user based on the user-submitted information.

Safely handling user input

Including user-submitted information in a SQL query is dangerous. A malicious user could enter SQL syntax into an input. If we just inserted this straight into a query this would mean they could execute dangerous commands in our DB. This is one of the most common causes of major hacks, so it's important to prevent it.

You should never directly insert user input into a SQL string:

If the user typed ; DROP TABLE users; into the username input we'd end up running that command and deleting all our user data!

The pg library uses something called "parameterized queries" to safely include user data in a SQL query. This allows it to protect us from injection. We can leave placeholders in our SQL string and pass the user input separately so pg can make sure it doesn't contain any dangerous stuff.

We use $1, $2 etc as placeholders, then pass our values in an array as the second argument to query. pg will insert each value from the array into its corresponding place in the SQL command (after ensuring it doesn't contain any SQL).

Challenge

Edit the post handler function in create-user.js to save the submitted user data in the database. Make sure to use a parameterized query.

Relational data

So far we've only touched the users table. Let's make the posts visible too.

1. Add a new route GET /posts

2. This should display a list of all the posts in your database

3. Once that's working amend the handler to also show the username of each post's author.

Hint: You'll need to use a join to get data from both tables in one query.

React makes dealing with the DOM in JavaScript more like writing HTML. It helps package up elements into "components" so you can divide your UI up into reusable pieces.

React elements

Interacting with the DOM can be a frustrating experience. It requires lots of awkward lines of code where you tell the browser exactly how to create an element with the right properties.

Even if we create our own function to handle some of the repetitive parts it's a little hard to read:

This is frustrating because there is a simpler, more declarative way to create elements: HTML.

Unfortunately we can't use HTML inside JavaScript files. HTML can't create elements dynamically as a user interacts with our app. This is where React comes in:

This variable is a React element. It's created using a special syntax called that lets us write HTML-like elements within our JavaScript.

The example above will be transformed into this normal JS:

This function call returns an object that describes your element:

React builds up one big tree structure of all these element objects that represents your entire app. It then uses this tree to create the actual DOM elements for you. (This is called the virtual DOM, but you don't need to worry about that right now)

It can be helpful to remember that the HTML-like syntax is really normal function calls that return objects.

Templating dynamic values

JSX supports inserting dynamic values into your elements. It uses a similar syntax to JS template literals: anything inside curly brackets will be evaluated as a JS expression, and the result will be rendered. For example:

You can do all kinds of JS stuff inside the curly brackets, like referencing other variables, or conditional expressions.

Note on expressions

You can put any valid JS expression inside the curly brackets. An expression is code that resolves to a value. I.e. you can assign it to a variable. These are all valid expressions:

This is not a valid expression:

if blocks are statements, not expressions. The main impact of this is that you have to use ternaries instead of if statements inside JSX.

React components

React elements aren't very useful on their own. They're just static objects. To build an interface we need something reusable and dynamic, like functions.

A React component is a function that returns a React element.

Valid elements

A React element can be a JSX element, or a string, number, boolean or array of JSX elements. Returning null, undefined, false or "" (empty string) will cause your component to render nothing.

Composing components

Components are useful because JSX allows us to compose them together just like HTML elements. We can use our Title component as JSX within another component. It's like making your own custom HTML tags.

When we use a component in JSX (<Title />) React will find the corresponding Title function, call it, and use whatever element it returns.

Customising components

A component where everything is hard-coded isn't very useful. It will always return the exact same thing, so there's almost no point being a function. Functions are most useful when they take arguments. Passing different arguments lets us change what the function returns each time we call it.

JSX supports passing arguments to your components. It does this using the same syntax as HTML:

React component functions only ever receive one argument: an object containing all of the arguments passed to it. React will gather up any key="value" arguments from the JSX and create this object.

This object is commonly named "props" (short for properties). Using an object like this means you don't have to worry the order of arguments. So in this case our Title function will receive a single argument: an object with a "name" property.

You can use these props within your components to customise them. For example we can interpolate them into our JSX to change the rendered HTML:

Now we can re-use our Title component to render different DOM elements:

Non-string props

Since JSX is JavaScript it supports passing any valid JS expression to your components, not just strings. To pass JS values as props you use curly brackets, just like interpolating expressions inside tags.

Children

It would be nice if we could nest our components just like HTML. Right now this won't work, since we hard-coded the text inside our <h1>:

JSX supports a special prop to achieve this: children. Whatever value you put between JSX tags will be passed to the component function as a prop named children. You can then access and use it exactly like any other prop.

Now this JSX will work as we expect:

This is quite powerful, as you can now nest your components to build up more complex DOM elements.

Rendering to the page

You may be wondering how we get these React components to actually show up on the page.

React consists of two libraries—the main React library and a specific ReactDOM library for rendering to the DOM (since React can also to render Virtual Reality or Native mobile apps).

We use the ReactDOM.render() function to render a component to the DOM. It takes an element as the first argument and a DOM node as the second.

It's common practice to have a single top-level App component that contains all the rest of the UI.

Challenge

Time to create some components! Open up challenge.html in your editor. You should see the components we created above. Open this file in your browser too to see the components rendered to the page.

Create a new component called Card. It should take 3 props: title, image and children, that render into h2, img and p elements respectively.

Replace the p in the App component with a Card. Pass whatever you like as the 3 props (although here's an image URL you can use: https://source.unsplash.com/400x300/?burger).

React is designed to build dynamic apps with lots of interaction. A common difficulty with apps like this is keeping the DOM up-to-date as the user interacts. React has two concepts to help keep this manageable: "state" and "effects".

React state

State is data that changes while your application is running. This might be in response to user actions, or after a fetch request finishes.

In React all stateful values are stored in JS as special variables. We can render our UI based on these variables—when they change React will automatically re-run the component function and update the DOM to reflect the new state value.

Using state

Imagine we have a counter component. When the button is clicked we want the count to go up one:

We need some way to make our Counter function run again if this value changes.

The React.useState method can be used to create a "stateful" value. It takes the initial state value as an argument, and returns an array. This array contains two things: the state value, and a function that lets you update the state value.

It's common to use array destructuring to simplify this:

The setCount function lets us update our state value and tells React to re-run this component. E.g. if we called setCount(10) React will call our Counter component function again, but this time the count variable would be 10 instead of 0.

This is how React keeps your UI in sync with the state.

Event listeners

We have a function that will let us update the state, but how do we attach event listeners to our DOM nodes?

You can pass event listener functions in JSX like any other property. They are always formatted as "on" followed by the camelCased event name. So "onClick", "onKeyDown", "onChange" etc.

In this example we are passing a function that calls setCount with our new value of count.

Challenge 1

Time to add some state! Open up challenge-1.html in your editor. You should see the Counter component we just created. This is an example; you can delete it if you want.

Create a new component called Toggle. It should render a button that toggles a boolean state value when clicked. It should also render a div containing its children, but only when the boolean state value is true.

Example usage:

Side effects

React is designed to make it easy to keep your application in sync with your data/state. Component functions render DOM elements and keep them in sync with any state values.

But most apps need more than just a UI—there are also things like fetching data from an API, timers/intervals, global event listeners etc. These are known as "side effects"—they can't be represented with JSX.

We need a way to ensure our effects reflect changes in state just like our UI does.

Using effects

React provides another "hook" like useState() for running side-effects after your component renders. It's called useEffect(). It takes a function as an argument, which will be run after every render (by default).

Let's say we want our counter component to also update the page title (so the count shows in the browser tab). There's no way to represent this update using the JSX our component returns. Instead we can use an effect:

React will run the arrow function we passed to useEffect() every time this component renders. Since calling setCount will trigger a re-render (as the state is updated) the page title will stay in sync with our state as the button is clicked.

Skipping effects

By default all the effects in a component will re-run after every render of that component. This ensures the effect always has the correct state values.

If your effect does something expensive/slow like fetching from an API (or sorting a massive array etc) then this could be a problem.

useEffect() takes a second argument to optimise when it re-runs: an array of dependencies for the effect. Any variable used inside your effect function should go into this array:

Now our effect will only re-run if the value of count has changed.

Running effects once

Sometimes your effect will not be dependent on any props or state, and you only want it to run once (after the component renders the first time). In this case you can pass an empty array as the second argument to useEffect(), to signify that the effect has no dependencies and never needs to be re-run.

For example if we wanted our counter to increment when the "up" arrow key is pressed:

We add an event listener to the window, and pass an empty array to useEffect(). This will keep us from adding new event listeners every time count updates and triggers a re-render.

Cleaning up effects

Some effects need to be "cleaned up" if the component is removed from the page. For example timers need to be cancelled and global event listeners need to be removed. Otherwise you'd have a bunch of code running in the background trying to update a component that doesn't exist anymore.

If you return a function from your effect React will save it and call it if the component is removed from the page. React will also run it to clean up when a component re-renders (before the effects run again).

Let's clean up after our effect example from above:

The cleanup function we return will be called if the component unmounts (is removed from the page). That will ensure we don't keep running an unnecessary event listener and trying to update state that doesn't exist anymore.

Challenge 2

We're going to enhance our Toggle component from Part 3. You can either keep working in the same file or open up challenge-2.html to start fresh.

1. Edit the Toggle component so that the page title (in the tab) shows whether the toggle is on or off.

2. Then create a new component called MousePosition. It should keep track of where the mouse is in the window and render the mouse x and y positions.

3. Put MousePosition

Scope is the context a variable is available in. It defines what variables can be used in each part of your code. There are two kinds of scope: global and local.

Global scope

Everything at the "top-level" of your code is global. This means anything outside of functions or "blocks" like if statements.

The global scope is also shared across all normal script tags. This can be confusing as you can use variables that don't appear to exist in that JS file. For example:

Local scope

Variables inside of functions or "blocks" are locally scoped. A block is created by curly brackets, like if statements.

Local variables are not visible or usable outside of that function or block.

Nested scope

A local scope always has access to the scopes above it.

Here the if block can see the x variable as that is defined in the scope "above". However the console.log(err) will fail as the err variable is defined inside a block—a "lower" scope.

Think of your code as a series of nested one-way mirrors: code can see out into the scopes above, but not further down.

ES6

Variables defined with var are not block scoped, whereas those defined with let and const are. var is still function scoped though.

Generally you should always prefer let and const, since it can be confusing for variables to be accessible outside of a block.

Challenge

1. Open starter-files/challenge/index.html in your browser

2. You should see a JS error in the console.

3. Fix this error, and every other error that shows up

Don't worry about understanding all of the code, just try to make it work. This is mostly an exercise in debugging, so keep persisting until the app works like :

HTML is a markup language. It is used to "mark up" a document with extra information about what each thing is. This is useful because it let's us communicate the "semantics" of the document.

What even is "semantics"?

When we describe markup as "semantic" we mean it describes the structure of the document. It tells the browser what things are (rather than what content they contain or how they are styled).

For example we can make a <span> look like a button using CSS:

We could even add some JavaScript event handlers to it so it behaved like a button when clicked. However from the browser's perspective it has no meaning—it's not actually a button.

Why does this matter?

You may wonder why it's important for the browser to know what an element actually is, if it looks right and behaves the same. There are a few reasons why using semantic HTML is important.

Sensible defaults

Browsers have a bunch of built-in styles and behaviours you should take advantage of. Why re-create all of that from scratch when you could just override the bits you want to change.

This also means your page will still look okay if your CSS is broken or fails to load.

Screenshot of this page with no CSS at all

Complex behaviour

You probably won't remember to reproduce everything the browser does for you. For example buttons not only respond when clicked, but also when the "Enter" or "Space" keys are pressed. Built-in elements have lots of complex behaviours that are hard (or impossible) to reproduce. Think how complicated a <select> would be to build yourself!

Machine-readable

Third (and most importantly) semantic HTML is machine readable. By describing the structure of our page we allow computer programs to understand it as well as humans.

For example most web browsers now have a "reader" mode. You can click an icon to get a simplified view of an article (with all the ads, cookie banners etc removed). These rely on the article using elements like <header> and <article>to know what bits to keep. They can also apply custom styles to make it easier to read. If everything was in a div with custom CSS this wouldn't work.

This article about is a great overview of this topic if you're interested.

This is also very important for accessibility. The web is for everyone, including people who use other types of software to browse. For example visually-impaired users often use "screen readers", which read the page out loud.

Human brains are great at "pattern-matching"—e.g. if you see a rectangle with a blue background and rounded corners you assume it's something you can click on to trigger an action (i.e. a button). Your brain doesn't know or care if the underlying element was a div.

Computer programs like screen readers are not so good at this—they can't guess at behaviour based on how something is rendered. So instead they must use the underlying markup semantics to figure out what things are.

For example using heading tags (<h1>, <h2> etc) creates a page structure that lets a user quickly jump from section to section to find what they need (without waiting for the entire page to be read out loud).

Screenshot of Voiceover's headings menu for this page

This allows a visually-impaired user to get a quick overview of the structure of the page in the same was a sighted user does by scanning the headings.

So how do we make our HTML semantic?

There are almost 100 HTML elements nowadays, but you don't need to remember them all. The important thing is to remember that there might be a more specific tag than div or span for what you're making.

This especially applies to top-level "blocks" of the page. Fun fact: when HTML5 was in-progress the spec authors looked at thousands of existing websites to see what the most popular IDs on top-level elements were. They saw a ton of <div id="header">, <div id="main"> and <div id="footer">, which is why HTML5 added the <header>, <main> and <footer> tags.

Checklist

Here's a quick list to run through whenever you're picking an element:

• Is it a meaningful area of the page?

  Use an HTML5 block element like <header> or <footer>.

• Does it label the start of a new section?

  Use a heading (with the right level) like

Challenge

You're going to re-write an HTML page to use semantic HTML. Try to replace as many generic elements with more descriptive semantic ones as you can. When you're done it should contain no <div>s at all.

Setup

First you need to download the starter files. There's a box at the top of this page labelled "Download files via CLI". Click the copy button to copy the command, then run it in your Terminal. This will automatically download the files you need for this workshop.

Once you've downloaded the files you can move into that directory in your Terminal by running:

You can see what's in there by listing the files with:

You can open the challenge file in VS Code with:

And you can open the page in your default browser with:

You are of course welcome to navigate the files however you're comfortable, but it's a good idea to get some practice working in your Terminal.

Don't peek at the solution before you try the challenge!

Bonus challenge

There are a few missing things that aren't necessarily related to semantics, but are important for the page to have anyway. Try to find and fix some of these issues.

There's some useful info in .

In this workshop we will be learning SQL by running commands in our terminal.

Getting Started

Make sure you have installed and set up PostgreSQL.

We'll be using psql, the Postgres command-line interface. This lets you run SQL queries and also provides some extra commands for working with the database. These extras start with a backslash character (e.g. \c) whereas SQL is usually uppercase (e.g. CREATE DATABASE).

Setting up the workshop database

Download the starter files and cd into the directory. Type psql in your terminal to enter the Postgres command-line interface. You can type ctrl + d to exit this at any time.

To create a database use the CREATE DATABASE command and give it whatever name you like:

You should now be able to use \list to list all the databases on your machine. Hopefully the new blog_workshop is there. You can type q to exit this view.

You can then connect to the new database using the \connect:

Now you need to populate the database with some data. The init.sql file contains a bunch of SQL commands. They create some tables and then insert data into them.

You can use \include to run some SQL directly from a file (which saves a lot of typing):

If you run \dt you should see all the database tables we just created (blog_posts, blog_comments and users).

The schema

A "schema" represents all the different things in a database. It says what type of data goes in each column, what columns are in each table, and how tables relate to each other. The schema is represented by the initial SQL used to create the tables (here inside the init.sql file).

Data types

SQL requires us to specify what type of data we're going to use for each entry in advance. Here's a small subset of available types:

SERIAL

An auto-incrementing number. Useful for IDs where each new entry needs a unique value. SQL will automatically create this when you inser an entry.

VARCHAR(255)

A variable-length string. The number in brackets specifies the maximum number of characters.

TEXT

A string of any length.

INTEGER

A whole number (like 20). No fractions allowed.

Constraints

A way to provide additional fine-tuning of a data type. Think of it like input validation. Here are a few useful constraints:

NOT NULL

This value is required and must always be set.

PRIMARY KEY

This value is the unique identifier for this entry into the table. Often a SERIAL so you don't have to worry about creating unique IDs yourself.

REFERENCES

This value must match one in another table, like users(id). Used to link tables together so you can find related information (e.g. which user wrote this blog post).

Our blog database

This specific database represents a blog site. It has users who can write blog posts, and blog posts that can contain comments.

A blog post has to have an author, so each entry in blog_posts has a user_id, which REFERENCES an id in the users table. This links the two together, so for any given post we can always find the author.

Comments are linked to both a user and a blog_post, so they have two REFERENCES: post_id and user_id.

Here is the example schema for the blog_post table:

Retrieving data

Here's a quick overview of some SQL commands used to retrieve data from a database.

SELECT

retrieves data from a table. You need to combine it with FROM to specify which table. For example:

would retrieve the first_name column for every row in the users table.

Note you can provide comma-separated lists of column names and table names if you want to select multiple things. You can also use the * character to select all columns.

WHERE

is a clause that qualifies a SELECT. It lets you filter which rows are retrieved based on the values in that row. For example:

would retrive the first name column for any users with an ID of 1.

AND, OR and NOT

are operators for expressing logic in your WHERE clauses. They let you apply multiple conditions. For example:

would retrieve the first name column for any users with an ID of 1 or 2.

IN

The operator lets you match against a list of values in your WHERE clause. For example:

would select the first name column for any users with an ID of 1 or 2.

This is similar to the OR operator we saw above.

Challenge 1: retrieving data

1. Select specific columns

   Using , retrieve a list of only usernames and locations from the users table

   Expected Result

Creating and updating data

Here's an overview of SQL commands used to add data to a database.

INSERT INTO

lets you add a new row into a table. You specify a table name and list of columns, then a list of values to insert. The values have to match positions with their respective columns (like function arguments in JS).

would create a new user row with a username of 'oliverjam' and first name of 'oli'.

UPDATE

lets you change existing data in a table. You provide the table name, then the name and new value of each column. You also need to provide a WHERE clause to select which rows to update, otherwise every row will be changed.

would update the first name of the user with username "oliverjam" to be "oliver".

RETURNING

You can access the created/changed rows with a RETURNING clause after your INSERT or UPDATE. This lets you specify which columns you want back. This saves you doing a whole extra SELECT after an insert just to get the new entry's ID.

Would return:

Creating and updating data challenges

1. Adding a new post

   Using and RETURNING, add a blog post with the text "Hello World" to the user with ID 1. Return the text content and user ID of the inserted post.

   Expected Result

Combining tables

We can use s to select columns from multiple tables at once, based on a relation they share. Joins effectively combine multiple tables into one temporary table for you to query.

There are different types of joins that determine exactly what data is returned. Since we're selecting from multiple tables we namespace our columns with the table name and a ., just like object access in JavaScript (e.g. SELECT users.username, blog_posts.text_content).

INNER JOIN

selects rows that have matching values in both tables being selected from. For example if we wanted to select all the users who have blogposts, then get their usernames and their blog posts' text content:

INNER JOIN returns only the the users that have blog posts.

LEFT JOIN

selects every entry in the first table you name, but only matched records from the second. For example if we wanted a list of every user, plus their blog posts' text content (if they have any):

LEFT JOIN selects one extra row here compared to INNER JOIN: the final user "Spont1935" who has no blog posts.

RIGHT JOIN

is like the opposite of LEFT JOIN. With our blog post data the result would be the same as an INNER JOIN, since every post must have an author.

Combining tables challenges

1. Selecting users and comments

   Using select every user's location, plus the content of any comments they've made.

   Expected Result

Bonus: Sub queries

You can nest SQL expressions. For example:

is the equivalent of:

if there's a human with ID 1 and name 'oli'. The nested query is resolved first, similar to using brackets in maths.

Add a comment to a post

Add a new comment to the post_comments table. It should have a user ID of 3 and text content 'Interesting post'. The comment should be linked to whichever post has text content of 'Peculiar trifling absolute and wandered vicinity property yet.' (i.e. its post_id should be the ID of that post).

You can then run SELECT text_content FROM post_comments WHERE post_id = 2; to test for the expected result.

Expected Result