DEV Community: Rob Kendal {{☕}}

Exciting news for remote dev job seekers

Rob Kendal {{☕}} — Tue, 22 Aug 2023 13:58:10 +0000

This will be BIG news for tech recruiters and software/web dev job hunters.

If you're keen to uncover the latest remote jobs in the UK then love my latest project: Remote Dev Jobs UK

What's more, all roles will be fully, 100% remote!

This simple, easy to use platform is ideal for:

Devs of all levels looking to to search for and find their perfect dev role or other job in the tech industry.
Recruiters and hiring managers looking to find new candidates for live roles

It's currently in development, but you can check it out and join the waiting list today 👉 https://remotedevjobs.uk/

Build a restful Node API server using JSON and TypeScript

Rob Kendal {{☕}} — Thu, 10 Aug 2023 23:00:00 +0000

A while ago I wrote a popular article on how to build a RESTful Node API server. This and it's accompanying GitHub repo, went down well and even became part of the curriculum in a US university course!

However, times and technology move on. After revisiting the repo and the code, I decided to revamp and rewrite from scratch, this time using not only the latest version of Express, but using a slightly different architecture and structure in the form of the controller and routes pattern. Also, for you TypeScript fans out there the new and updated version is fully type aware and is written entirely in TypeScript. Good times!

You can check out the Node API starter kit with TypeScript on GitHub, but for now, let's dive in!

1. Node API project setup

I like to start any project (especially smaller ones like this skeleton Node API server) by installing dependencies we'll need and defining a skeleton folder and files structure. With that in mind, let's create a folder on your machine where the project will live and kick things off with a package.json file:

pnpm init

We'll be using pnpm as the package manager here. If you've not installed or used pnpm before, then head over to pnpm.io and get it installed on your machine. Alternatively, you can use npm or yarn just as easily if you prefer.

Next, let's get a folder structure in place like this:

/projectfolder
--/data
  --users.json
--/server
--/--/controllers
        --types.ts
        --users.ts
--/--/routes
        --index.ts
        --users.ts
server.ts
package.json
tsconfig.json

Installing dependencies and build scripts

With pnpm ready to go and our skeleton file structure in place, let's install some dependencies and add the build scripts to the package.json file.

In your package.json file, add the following JSON:

"scripts": {
  "start": "nodemon server.ts"
},

This is all we need for now, so let's move onto our dependencies. Run the following commands, separately, in your console:

pnpm add -D @types/express @types/node ts-node typescript

This command will add some dev dependencies, namely some TypeScript types information for Express and Node, as well as TypeScript itself, and finally, ts-node, which is a library that allows us to run TypeScript in Node environments without having to precompile it first.

Next, let's add some regular dependencies like this:

pnpm add express module-alias nodemon

Here we're adding a couple of packages:

Express, which is a web application framework that offers us lots of HTTP utility methods and is the defacto standard for creating node-based API's.
Nodemon, (optional) a file-watcher that helps keep an eye on our files, reloading things if we change them during development.
Module-alias, again optional but we'll use this handy package to save us from having to type some ugly file paths for our module imports. We'll cover this later, but it's not a requirement for this project.

Configuring TypeScript

Finally, as part of the project set up, we need to give TypeScript some solid defaults to work with. Open the ./tsconfig.json file and add the following:

{
  "compilerOptions": {
    "forceConsistentCasingInFileNames": true,
    "esModuleInterop": true,
    "outDir": "dist",
    "rootDir": "./",
    "target": "ESNext",
    "skipLibCheck": true,
    "strict": true,
    "sourceMap": true,
    "lib": ["ESNext"],
    "baseUrl": "./",
    "paths": {
      "@controllers/*": ["./server/controllers/*"],
      "@routes/*": ["./server/routes/*"],
      "@data/*": ["./data/*"]
    }
  },
  "exclude": ["node_modules"]
}

Adding some basic user data

Our Node API server with TypeScript is founded on its ability to deal with data stored in JSON files. For us, we're going to start with some simple user data, so open up the ./data/users.json file and flesh it out:

{
  "users": [
    {
      "name": "king arthur",
      "password": "password1",
      "profession": "king",
      "id": 1
    },
    {
      "name": "rob kendal",
      "password": "password3",
      "profession": "code fiddler",
      "id": 2
    },
    {
      "name": "ash ketchum",
      "password": "pikapika",
      "profession": "pokemon botherer",
      "id": 3
    }
  ]
}

Nothing too fancy, just some simple JSON data about a typical user including their name and profession.

2. Building the new server.ts file

With our project structure and dependencies in place, let's move on to building out our API server. Open up the ./server.ts file and paste the following into it:

import 'module-alias/register';
import http from 'http';
import express, { Express } from 'express';
import routes from '@routes/index';

const router: Express = express();

router.use(express.urlencoded({ extended: true }));
router.use(express.json());

router.use((req, res, next) => {
  // set the CORS policy
  res.header('Access-Control-Allow-Origin', '*');
  // set the CORS headers
  res.header(
    'Access-Control-Allow-Headers',
    'origin,X-Requested-With,Content-Type,Accept,Authorization'
  );
  // set the CORS method headers
  if (req.method === 'OPTIONS') {
    res.header('Access-Control-Allow-Methods', 'GET, PUT, POST, DELETE');
    return res.status(200).json({});
  }
  next();
});

router.use('/', routes);

/** Error handling */
router.use((_, res) => {
  const error = new Error('not found');
  return res.status(404).json({
    message: error.message,
  });
});

// Start that server
const httpServer = http.createServer(router);
const PORT: string | number = process.env.PORT ?? 8080;
httpServer.listen(PORT, () =>
  console.log(`API server alive and kicking on port ${PORT}`)
);

Although this is a relatively small file, there's a lot going on in it, so let's break it down...

The imports

Right at the start, we bring in some dependencies:

import 'module-alias/register';
import http from 'http';
import express, { Express } from 'express';
import routes from '@routes/index';

The very first line where we import module-alias/register is an important line if you want to be able to use aliased paths for your module imports. There's an entire section coming up where we'll discuss this, but for now, just note that if you want to use imports like import thing from '@routes/myawesomefile' then you'll need this import right at the top of your project's entry point.

We also bring in the http utility from the built-in http module, then Express (both the main package and the Express type for TypeScript) and finally our routing information from the @routes/index file — we'll create this later on so don't worry about it for now.

Setting up the Express router

With our imports done, we can create an instance of the Express framework, and then set up some encoding rules to make sure the data we receive is encoded in the same way as is described in the OPTIONS argument that's sent before the main API request.

const router: Express = express();

router.use(express.urlencoded({ extended: true }));
router.use(express.json());

We also make use of the json() method so that our API server will parse JSON requests.

Configuring CORS

CORS (Cross-Origin Resource Sharing from MDN) can be a horrendously frustrating part of development life. It helps to restrict the origins from which HTTP requests are made. However, in doing so, it can thwart many a local development environment by cutting off access to some legitimate requests.

That said, it is a necessary and important part of any API set up as it helps prevent bad actors from making requests from unauthorised URLs or origins.

Our little server will be no different so let's set up CORS for our API server now:

router.use((req, res, next) => {
  // set the CORS policy
  res.header('Access-Control-Allow-Origin', '*');
  // set the CORS headers
  res.header(
    'Access-Control-Allow-Headers',
    'origin,X-Requested-With,Content-Type,Accept,Authorization'
  );
  // set the CORS method headers
  if (req.method === 'OPTIONS') {
    res.header('Access-Control-Allow-Methods', 'GET, PUT, POST, DELETE');
    return res.status(200).json({});
  }
  next();
});

This is a simple portion of code that basically sets which origins our API server will allow access from, which types of requests (e.g. what's been set in the header), and then what sorts of methods we'll allow — e.g. here we're allowing the four main CRUD methods, GET, PUT, POST, and DELETE.

Note that in our example here, we're allowing all origins as denoted by the '*' symbol. In production, you'll definitely want to restrict calling of this API to perhaps just your app's url(s), depending on your needs!

Adding in the routes and handling errors

Of course, our API server will be of no use if we don't let it handle some routes. That's where the following line comes in:

router.use('/', routes);

We've imported our routes object right at the start of the file and this will be further broken down (as we'll see later on) into sub-routes, each with their own controller and router handling logic. In our main server file, however, we just need to let the server know that anything starting with / will be handled by the imported routes object.

Next up, we'll cater for any routes that aren't handled above:

/** Error handling */
router.use((_, res) => {
  const error = new Error('not found');
  return res.status(404).json({
    message: error.message,
  });
});

Essentially, what we're saying here is 'any route that isn't already catered for, return an error message and a 404 status'.

There's lots more you could do here to expand on it or handle different types of errors and that's probably quite a good idea to do in a larger app, or as your app begins to scale. For now, however, we can start simply and handle the most basic error where a request has tried to call a route that doesn't exist.

Starting the server

Finally, we're ready to kick off the server and get things running. This last bit of code creates an instance of a http server, creates a port for the server to run on, and finally starts the server:

// Start that server
const httpServer = http.createServer(router);
const PORT: string | number = process.env.PORT ?? 8080;
httpServer.listen(PORT, () =>
  console.log(`API server alive and kicking on port ${PORT}`)
);

We try to use a PORT option that might be present in an environment variable, hence the process.env.PORT part, but if one isn't available, then the default port is simply '8080'.

2a. Module aliases

Before we go ahead with the meat and potatoes of the API server, we need to quickly go over module path aliasing. By default, you'll always need to import a local module or package from another file using a relative path. This is fine when your files are close together.

However, when they're separated by different levels or in a larger, more complex folder structure, then you can end up with ugly (and confusing) import statements like this:

import { SomeThing } from '../../../../path/to/file';

Not the worst thing in the world, but it gets messier the more of these you have and also creates a headache when you want to migrate or move files!

It's much nicer to be able to do something like this:

import { SomeThing } from 'module/file';

Some bundlers and code packagers will do this for you. If you've used Rollup, Vite or even Create React App, then you'll have lots of wonderful support from bundlers like Webpack that can offer some of this module path aliasing out of the box or with a simple config setting.

TypeScript also has a nice idea of paths and in fact, we've already set this up earlier in our process. Check out the ./tsconfig.json file towards the end of the file:

"paths": {
  "@controllers/*": ["./server/controllers/*"],
  "@routes/*": ["./server/routes/*"],
  "@data/*": ["./data/*"]
}

Here, we've added a couple of helper routes so that wherever we have @controllers/any_file_path_here this will be replaced by TypeScript with ./server/controllers/any_file_path_here. Neat!

I've used little '@' symbols here because it looks pretty cool and I like it, but it's not part of the syntax, you could use whatever you like or just leave it as 'controllers/'.

Unfortunately, whilst we can configure this from a TypeScript point of view, Node doesn't know what to do with this. Your options are to implement some sort of middle man transpiler to handle these paths for us and then run the server, or we can use the handle module-aliases package, which handily we installed earlier!

The only downside (and it's a small downside) is that we have to duplicate our path aliases into our package.json file as outlined here:

"_moduleAliases": {
  "@controllers": "./server/controllers",
  "@routes": "./server/routes",
  "@data": "./data"
},

We add in the extra "_moduleAliases" property into the package.json file and then everything should work nicely and we can use our funky, shorter paths 👍.

3. Mapping the routes

With our server prepped and ready to go, we need to feed it some routes to handle and serve. When someone requests an API endpoint such as https://api.domain.com/users/123 we need to have a matching route within our server that can listen for and accept the route, then provide some sort of meaningful response to the requestee.

In our case, we're going to be loading and saving JSON data about users, such as username, password, name, etc. For that, we need to define a series of user endpoint routes and we'll do that within the ./server/routes/users.ts file:

import type { Router } from 'express';
import {
  getUser,
  getUsers,
  addUser,
  updateUser,
  deleteUser,
} from '@controllers/users';

const userRoutes = (router: Router) => {
  router.get('/users', getUsers);
  router.get('/user/:id', getUser);
  router.post('/users', addUser);
  router.put('/user/:id', updateUser);
  router.delete('/user/:id', deleteUser);

  return router;
};

export default userRoutes;

First, we're bringing in the Router type from Express as we'll be passing in a router object to our user routes handling code in a moment. Next, we import some common CRUD-style handler functions from our controller, which we'll define in the next part.

We've got a getUser function which will fetch and return a single user, and then getUsers which will, in turn, fetch us multiple users. After that, we handle adding a new user, updating a user, and deleting a user from our files.

We haven't touched on the concept of a controller yet, but a controller's purpose is to deal with the data handling part of the request. The routes and router are designed to merely handle the incoming request and route it to the appropriate place. Once a route has been captured, the controller is called upon to do something meaningful whether that's fetching some data, or manipulating it in some way before saving it against a data store. In our case, this is a JSON file stored on disk.

Next, we create a userRoutes function which accepts an instance of a Router object, which is an Express item that can be used to define routes. That's what we do next. We call router.[method] where 'method' is the request type (e.g. GET or POST), passing it a route we want to handle (e.g. '/users') and the function from our controller which will deal with the data business for that route.

Where we have something like :id this is a route parameter. It will be substituted with a real world value when the API route is called. We can use this within our controller to access this substituted value and use it to access specific data. For example, in the route /user/:id the real API would be called like /user/AFC34OI where the value AFC340I is the 'id' value of a user and we can use it to search a database or similar for said user.

After we add a bunch of supporting CRUD-like routes and their controller handlers, we return the updated router object from the function.

Adding user routes to our main router

Doing the above is not quite enough to have the API handle those routes for us. We need to connect the user route handlers to the main Express router.

Open up the ./server/routes/index.ts and add in the following:

import express from 'express';

// Import individual route profiles from controllers
import usersRoute from '@routes/users';

const router = express.Router();

// Pass our router instance to controllers
router.use('/users', usersRoute(router));

export default router;

We pull in our usersRoute here and this is where you'd add in any other additional routes that you create later down the line.

Next, we create an instance of the Express Router. In the next line down we fire off the router.use() function and supply it with our base users route, /users and pass it the handling function, usersRoute which itself is passed the express router.

Any route that begins with /users will be handled by our usersRoute handler.

Finally, we export the router that we consumed in our server.ts file earlier. All done, nice and simple.

4. Creating our controller

The controller is where our data handling will occur. It doesn't know about what route it's serving, just that it has a specific job to fetch or update certain data and respond to the request with that data in a particular shape or format (e.g. JSON, text or XML).

For us, we'll start simply by showing how handle fetching all the users from the store. Open up the ./server/controllers/users.ts file and add in the following:

import type { Request, Response } from 'express';
import type { UserList, User } from './types';
import fs from 'fs/promises';

const dataPath = 'data/users.json';

export const getUsers = async (req: Request, res: Response) => {
  try {
    const data = await fs.readFile(dataPath, {
      encoding: 'utf8',
    });

    res.status(200).send(JSON.parse(data));
  } catch (error) {
    res.status(500).send('An error occurred when fetching the users');
  }
};

export default {
  getUsers,
};

We import some types from Express and our locally defined ones (see the next section) and then the fs file handling package from Node. This will help us deal with reading from and writing to our local files.

With getUsers we use the fs package to asynchronously read from the users.json file and send it straight back to the request via the res or 'response' object. If we're successful, we set the status to 200 (i.e. a successful response), and parse the users data into JSON for the response.

Finally, we can export the getUsers function as part of a default object.

Notice that the main body of code in getUsers is wrapped in a try catch block. If an error occurs, it's captured here and an appropriate status is returned (a 500 code) along with a simple string message. There's lot of different error handling and logging approaches, but this is fine for a simple app like ours.

User types for TypeScript

In the last section, you'll see we imported some local types, namely UserList and User. You can add these or change them to your needs, but open up ./server/controllers/types.ts and add in the following:

export interface User {
  name: string;
  password: string;
  profession: string;
  id: number;
}

export interface UserList {
  users: User[];
}

Nothing too fancy or complex, but notice how the structure of the data here maps to that of our users JSON data from the beginning of the article.

5. Testing the API server

With our server all put together, the only sensible thing to do is to fire up the server and test it! Save all your files and then open up your nearest and favourite console or terminal and enter the command pnpm start and you should see the following:

API server alive and kicking on port 8080

Nothing too exciting here. Instead, head into a simple browser and navigate to http://localhost:8080/users/ and what you should see now is a list of our available users from our ./data/users.json file. Alternatively you could use an app like Postman or Rapid API to check your own API too and they'll work just as well.

6. Extending the API server with CRUD

We've missed a few parts out of the users.ts file for brevity, but here is the entire file for completeness. Whilst long, it should be fairly straightforward to scan and understand and a lot of the code is very similar, especially around updating and deleting users.

import type { Request, Response } from 'express';
import type { UserList, User } from './types';
import fs from 'fs/promises';

const dataPath = 'data/users.json';

export const getUsers = async (req: Request, res: Response) => {
  try {
    const data = await fs.readFile(dataPath, {
      encoding: 'utf8',
    });

    res.status(200).send(JSON.parse(data));
  } catch (error) {
    res.status(500).send('An error occurred when fetching the users');
  }
};

export const getUser = async (req: Request, res: Response) => {
  try {
    let user = {};
    const userId = req.params.id;
    const data = await fs.readFile(dataPath, {
      encoding: 'utf8',
    });

    if (data.length > 0) {
      const allUsers: UserList = JSON.parse(data);
      user = {
        ...allUsers.users.find((user) => user.id === Number(userId)),
      };
    }

    res.status(200).send(user);
  } catch (error) {
    res
      .status(500)
      .send(
        'An error occurred when fetching the user with id ' + req.params.id
      );
  }
};

export const addUser = async (req: Request, res: Response) => {
  try {
    const data = await fs.readFile(dataPath, {
      encoding: 'utf8',
    });
    const allUsers: UserList = JSON.parse(data);
    const newUser: User = req.body;

    // Note: this isn't ideal for production use.
    // ideally, use something like a UUID or other GUID for a unique ID value
    const newUserId = Date.now();

    newUser.id = newUserId;
    allUsers.users.push(newUser);

    await fs.writeFile(dataPath, JSON.stringify(allUsers, null, 2), {
      encoding: 'utf8',
    });

    res.status(200).send(newUser);
  } catch (error) {
    res.status(500).send('An error occurred when adding the new user');
  }
};

export const updateUser = async (req: Request, res: Response) => {
  try {
    const data = await fs.readFile(dataPath, {
      encoding: 'utf8',
    });
    const allUsers: UserList = JSON.parse(data);
    const userId: number = Number(req.params.id);
    const userToUpdate: User = req.body;

    allUsers.users = allUsers.users.map((user) =>
      user.id === userId ? { ...user, ...userToUpdate } : user
    );

    console.log(allUsers);

    await fs.writeFile(dataPath, JSON.stringify(allUsers, null, 2), {
      encoding: 'utf8',
    });

    res.status(200).send(allUsers);
  } catch (error) {
    res
      .status(500)
      .send('An error occurred when updating the user with id' + req.params.id);
  }
};

export const deleteUser = async (req: Request, res: Response) => {
  try {
    const data = await fs.readFile(dataPath, {
      encoding: 'utf8',
    });
    const allUsers: UserList = JSON.parse(data);
    const userId: number = Number(req.params.id);

    allUsers.users = allUsers.users.filter((user) => user.id !== userId);

    await fs.writeFile(dataPath, JSON.stringify(allUsers, null, 2), {
      encoding: 'utf8',
    });

    res.status(200).send(allUsers);
  } catch (error) {
    res
      .status(500)
      .send('An error occurred when deleting the user with id' + req.params.id);
  }
};

export default {
  getUsers,
  getUser,
  addUser,
  updateUser,
  deleteUser,
};

As a challenge you could look to extend this to handle some other user editing options, or refactor it to reduce some of the similar code across the different functions.

Enjoy your fully functional Node-based API server

There's lots more you could add to extend this, such as authentication handling, talking to a database, different routes, and so on. As it stands, we've got a fully functional API server base that will happily serve you some information from a JSON file store.

You can visit the GitHub repository for the starter API server to download, checkout or fork to your heart's content.

If there's anything I've missed or that you'd like to know more about, let me know in the comments or shoot me an email to me[at]robkendal.co.uk.

How to fix 'Property does not exist on type Window in TypeScript' error

Rob Kendal {{☕}} — Wed, 23 Mar 2022 09:08:41 +0000

If you've been doing something with an external library, global variable or anything that involved the native Window object in TypeScript, you may have come across this error:

Property does not exist on type 'Window & typeof globalThis'.ts (123)

It's a pain, but really simple to fix, so let's get to it!

Discovering the 'Property does not exist on type Window in TypeScript' error

I was recently working on a client site and it involved using the excellent Cloudinary service. They have some equally excellent embeddable widgets which only require a bit of simple JS to drop in. Here's a snippet of the code:

const myWidget = window.cloudinary.createUploadWidget(options, processResults);
// ...rest of the file

The problem is, this was a React app in Next.js and a TypeScript codebase at that! The code worked fine, but the classic 'Property does not exist on type Window in TypeScript' error flagged up on the build command and TypeScript complained about it endlessly.

Identifying the problem

The Window type is defined in the lib.dom TypeScript module (as per the following documentation on TSDoc. You can see we have the global Window object definition here with a ton of properties.

If you need anything not defined in this list, however, then that's when you'll hit the Property does not exist on type 'window & typeof globalthis'.ts style error. Common examples of this are when you add external libraries from Google for their analytics or Tag Manager, or, in my case, Cloudinary.

Cloudinary added it's own cloudinary object to the global window object provided by the browser, but TypeScript has no idea what it is or what types it has because they're not defined.

This is one of those cases where the error is actually pointing us in the right direction.

Fixing the 'Property does not exist on type Window in TypeScript' error

Fortunately for us, the fix is quite simple and involves three steps:

Creating an index.d.ts file somewhere in our project.
Editing the file to define the types on the Window object.
(optional) adding a reference to the file in the tsconfig.json file.

Starting with number 1, you'll need to add the following into your index.d.ts file:

export {};

declare global {
  interface Window {
    somePropertyHere: any;
  }
}

If you don't have such a file, then create a folder in your project root or src folder called types. In here, add a new file called index.d.ts and then add the previous code snippet in there.

If you already have an index.d.ts file or a global.d.ts (or any other declared project types file) in your project with other type definitions in it, then you may not need the export {} line. You can omit that part and add the rest.

You can define whatever other properties you'd like in here as per your project needs, e.g.

export {};

declare global {
  interface Window {
    cloudinary: any;
    gtag: (...args: any[]) => void;
  }
}

In the above snippet, you'll see I added the cloudinary global object with a type of any as, unfortunately Cloudinary don't seem to offer a TypeScript option for their widgets so we're unsure what the cloudinary object will contain. However, with the gtag one, we know that it is a function that has a void return type.

Where possible, always try to strongly type your properties if you can, rather than opting for any.

Finally, if you're still experiencing issues, you might need to do one last step to wire things up. Take a note of your index.d.ts file's location and head into your tsconfig.json file, which should be in the root of your project:

{
  "compilerOptions": {
    // ... other settings
    "typeRoots": ["./src/types", "./types"]
  }
}

Under the typeRoots property (an array), make sure you have a path to the containing folder for your index.d.ts file. In my case it was in ./src/types so I added that in my tsconfig.json file.

Wrapping up

And it's a simple as that. If you've been plagued by TypeScript's complaints about a 'Property does not exist on type Window in TypeScript' error, you should have the knowledge and really simple steps to fix that once and for all.

How to build a multi-image carousel in React and Tailwind

Rob Kendal {{☕}} — Thu, 10 Mar 2022 09:13:41 +0000

I had a client project recently that required some nifty coding to produce a multi-item carousel in React. Really, it was a multi-image carousel with a few extra bits, but as we'll soon see, what we'll build in this article can be easily modified to suit whatever multi-items you'd like to stuff into your carousel.

Let's get building.

What we'll be building

To be honest, it's difficult to find a solid definition of what exactly a 'multi-item carousel' or 'multi-image carousel' is, let alone finding a good example of one built in React. Sometimes it seems the terms 'carousel', 'slider', and others get all interchanged and mingled around to the point where it can be confusing...

My definition or requirements looked like this:

I wanted to create a fixed-width container that housed several child items (mainly images with overlays for my purposes) arranged horizontally with an equal gap between them. Any child items that overflowed the container's bounds would be hidden offscreen, yet scrollable to bring them into view along the horizontal axis.

See the following image to illustrate what I mean:

There are some existing packages in the wild, such as this one react multi carousel, which is worth a look, but often they're too complex, or just not what we need.

What we're building here is a simple, minimal (as possible), example that fits the definition above, and to my mind embodies the wider definition of a multi-item carousel built in React.

You can view the finished multi-item carousel here https://codesandbox.io/s/react-multi-item-carousel-uvmchp.

Also, there's a repo with the code in here, react-carousel on GitHub.

Tools used

For this React multi-item carousel, I've chosen to build it using the really popular Vite.js and Tailwind CSS. Tailwind just allows for rapid building of websites and apps by removing all the fluff of starting with a blank CSS slate and gives us the utility-based CSS building blocks to quickly put things like this together.

Vite is just used to bundle and build our JavaScript so React works, but you can use whatever you like. Same with Tailwind -- use any CSS you like, but obviously you'll have to code the matching styles that Tailwind gives us into your version.

The key point in the demo is the carousel.jsx component that we'll see in a minute.

Building the multi-image carousel in React

Enough preamble; let's build our multi-image carousel in React and Tailwind, starting with the scaffolding parts.

The exact set-up with Vite and Tailwind is outside the scope of this article, so I'm assuming you have some sort of React project set up and ready to go that also has Tailwind installed and configured.

Carousel data

In the finished demo you'll see that each carousel item looks like this:

<div key={index} className="...">
  <a
    href={resource.link}
    className="..."
    style={{ backgroundImage: `url(${resource.imageUrl || ''})` }}
  >
    <img src={resource.imageUrl || ''} alt={resource.title} className="..." />
  </a>
  <a href={resource.link} className="...">
    <h3 className="...">{resource.title}</h3>
  </a>
</div>

And that's it. That's a single carousel item. I've omitted the Tailwind classes from this to keep it a little cleaner, but you can see that this could be whatever you like to show in the carousel, I've just gone with images inside a clickable link, then a heading level 3 that will be displayed on hover.

The main point here is that we're pulling data in to use where we have things like href={resource.link} from a file data.json, which looks like this:

{
  "resources": [
    {
      "title": "Find me on Twitter",
      "link": "https://twitter.com/kendalmintcode",
      "imageUrl": "https://placeimg.com/300/300/any"
    },
    {
      "title": "Welcome to Ark Labs",
      "link": "https://ark-labs.co.uk",
      "imageUrl": "https://placeimg.com/300/300/animals"
    },
    {
      "title": "Some sort of third title",
      "link": "https://twitter.com/kendalmintcode",
      "imageUrl": "https://placeimg.com/300/300/architecture"
    },

    ...other entries

    {
      "title": "Super item number the last",
      "link": "https://twitter.com/kendalmintcode",
      "imageUrl": "https://placeimg.com/300/300/tech"
    }
  ]
}

You can see we have a title, link URL and image source URL in an array of objects called resources. When this data.json file is imported into the carousel component we can loop through each resource item, which will become a single carousel item.

Again, you could bend this to your needs and this data might even come from an API (the real project I use this in does just that), but it'll keep things cleaner inside our carousel component for now.

Basic styles

The only other thing to highlight from the demo point of view is the starting styles. In the main App component, app.jsx we have this:

function App() {
  return (
    <div className="2xl:container 2xl:mx-auto 2xl:px-0 py-3 px-10">
      <Carousel />
    </div>
  );
}

Really simple and all it's doing is pulling in the carousel component and wrapping it in a div with some basic tailwind classes on it, to fix the width on very large screens and add some nice padding around the carousel for nicer display purposes.

Next, in the styles.css file, some basic CSS:

@tailwind base;
@tailwind components;
@tailwind utilities;

html,
body {
  padding: 0;
  margin: 0;
}

* {
  box-sizing: border-box;
}

Up top we have the necessary Tailwind imports, then we just strip off the padding and margin from body and HTML, and set all box-sizing to border-box.

Again, these styles aren't super important for your purposes, but I want to be clear up-front about where some minor little display styles are and what they're doing.

The multi-item carousel component

And now, the part you've been waiting for, the main carousel component itself. In the carousel.jsx component you'll see the following imports:

import { useState, useRef, useEffect } from 'react';

// Data
import data from './data.json';

We've already mentioned the data that we're pulling in from our JSON file, but yours might be coming from your own JSON data, an API, a database, wherever. The key point here is that we're going to be using three hooks from React, useState, useRef and useEffect.

The carousel JSX

Perhaps counterintuitively we'll start with the output JSX from the component. It looks like this:

return (
  <div className="carousel my-12 mx-auto">
    <h2 className="text-4xl leading-8 font-semibold mb-12 text-slate-700">
      Our epic carousel
    </h2>
    <div className="relative overflow-hidden">
      <div className="flex justify-between absolute top left w-full h-full">
        <button
          onClick={movePrev}
          className="hover:bg-blue-900/75 text-white w-10 h-full text-center opacity-75 hover:opacity-100 disabled:opacity-25 disabled:cursor-not-allowed z-10 p-0 m-0 transition-all ease-in-out duration-300"
          disabled={isDisabled('prev')}
        >
          <svg
            xmlns="http://www.w3.org/2000/svg"
            className="h-12 w-20 -ml-5"
            fill="none"
            viewBox="0 0 24 24"
            stroke="currentColor"
            strokeWidth={2}
          >
            <path
              strokeLinecap="round"
              strokeLinejoin="round"
              d="M15 19l-7-7 7-7"
            />
          </svg>
          <span className="sr-only">Prev</span>
        </button>
        <button
          onClick={moveNext}
          className="hover:bg-blue-900/75 text-white w-10 h-full text-center opacity-75 hover:opacity-100 disabled:opacity-25 disabled:cursor-not-allowed z-10 p-0 m-0 transition-all ease-in-out duration-300"
          disabled={isDisabled('next')}
        >
          <svg
            xmlns="http://www.w3.org/2000/svg"
            className="h-12 w-20 -ml-5"
            fill="none"
            viewBox="0 0 24 24"
            stroke="currentColor"
            strokeWidth={2}
          >
            <path
              strokeLinecap="round"
              strokeLinejoin="round"
              d="M9 5l7 7-7 7"
            />
          </svg>
          <span className="sr-only">Next</span>
        </button>
      </div>
      <div
        ref={carousel}
        className="carousel-container relative flex gap-1 overflow-hidden scroll-smooth snap-x snap-mandatory touch-pan-x z-0"
      >
        {data.resources.map((resource, index) => {
          return (
            <div
              key={index}
              className="carousel-item text-center relative w-64 h-64 snap-start"
            >
              <a
                href={resource.link}
                className="h-full w-full aspect-square block bg-origin-padding bg-left-top bg-cover bg-no-repeat z-0"
                style={{ backgroundImage: `url(${resource.imageUrl || ''})` }}
              >
                <img
                  src={resource.imageUrl || ''}
                  alt={resource.title}
                  className="w-full aspect-square hidden"
                />
              </a>
              <a
                href={resource.link}
                className="h-full w-full aspect-square block absolute top-0 left-0 transition-opacity duration-300 opacity-0 hover:opacity-100 bg-blue-800/75 z-10"
              >
                <h3 className="text-white py-6 px-3 mx-auto text-xl">
                  {resource.title}
                </h3>
              </a>
            </div>
          );
        })}
      </div>
    </div>
  </div>
);

Breaking that down a little, we start with a simple container and heading level 2:

<div className="my-12 mx-auto">
  <h2 className="text-4xl leading-8 font-semibold mb-12 text-slate-700">
    Our epic carousel
  </h2>
  <div className="relative overflow-hidden">... rest of carousel jsx</div>
</div>

Nothing too fancy thus far, we're just adding some vertical margins and displaying it centrally on the screen. With the heading, we're adjusting the size to suit our needs.

The div that features the relative overflow-hidden classes will house our images or items and the left and right controls. We hide the overflow so we can scroll it into view later, and the relative class allows us to absolutely position the scroll buttons.

Next up, we have a block that houses our left and right scroll buttons:

<div className="flex justify-between absolute top left w-full h-full">
  <button
    onClick={movePrev}
    className="hover:bg-blue-900/75 text-white w-10 h-full text-center opacity-75 hover:opacity-100 disabled:opacity-25 disabled:cursor-not-allowed z-10 p-0 m-0 transition-all ease-in-out duration-300"
    disabled={isDisabled('prev')}
  >
    <svg
      xmlns="http://www.w3.org/2000/svg"
      className="h-12 w-20 -ml-5"
      fill="none"
      viewBox="0 0 24 24"
      stroke="currentColor"
      strokeWidth={2}
    >
      <path strokeLinecap="round" strokeLinejoin="round" d="M15 19l-7-7 7-7" />
    </svg>
    <span className="sr-only">Prev</span>
  </button>
  <button
    onClick={moveNext}
    className="hover:bg-blue-900/75 text-white w-10 h-full text-center opacity-75 hover:opacity-100 disabled:opacity-25 disabled:cursor-not-allowed z-10 p-0 m-0 transition-all ease-in-out duration-300"
    disabled={isDisabled('next')}
  >
    <svg
      xmlns="http://www.w3.org/2000/svg"
      className="h-12 w-20 -ml-5"
      fill="none"
      viewBox="0 0 24 24"
      stroke="currentColor"
      strokeWidth={2}
    >
      <path strokeLinecap="round" strokeLinejoin="round" d="M9 5l7 7-7 7" />
    </svg>
    <span className="sr-only">Next</span>
  </button>
</div>

One of the downsides to Tailwind is that the class lists get quite verbose and subsequent JSX gets a little longer, but we'll break each part down here.

Starting with the scroll left/right button container:

<div className="flex justify-between absolute top left w-full h-full">
  ...buttons
</div>

We position the block absolutely, add flexbox to the display type, then push the child items (i.e. left/right buttons) to the far left and right edges using justify-between. Finally, we force the container to have full width and height.

Next up, the buttons:

<button
  onClick={movePrev}
  className="hover:bg-blue-900/75 text-white w-10 h-full text-center opacity-75 hover:opacity-100 disabled:opacity-25 disabled:cursor-not-allowed z-10 p-0 m-0 transition-all ease-in-out duration-300"
  disabled={isDisabled('prev')}
>
  <svg
    xmlns="http://www.w3.org/2000/svg"
    className="h-12 w-20 -ml-5"
    fill="none"
    viewBox="0 0 24 24"
    stroke="currentColor"
    strokeWidth={2}
  >
    <path strokeLinecap="round" strokeLinejoin="round" d="M15 19l-7-7 7-7" />
  </svg>
  <span className="sr-only">Prev</span>
</button>

I'm just showing the 'prev' button for now as both buttons are the same, just the SVG icon differs between left and right chevron. We're assigning the function movePrev to the button's click handler. The other button has a matching moveNext click handler and we'll define these click handlers in the logic section coming up.

Both buttons have a disabled property that's calculated using the isDisabled() function that we'll also cover next in the logic section of the article.

And each button has a butt load of Tailwind classes on it, but they essentially do the following:

Add base background colours and opacity
Add hover colors with less opactiy
Add disabled styles (i.e. when you can't move left or right any further)
Set the height and width
Set some base transitions just for nice look and feel when you hover over them

The other thing of note here is that we've included a simple span element with the sr-only class so that screen readers can still understand what they're dealing with. If we just have images or SVGs on there it'll be harder for less abled or visually impaired users to understand what the button is and does.

We're using SVG icons from the excellent (and free!) heroicons, which is another Tailwind CSS product, but you could use your own icons, no icons, whatever you like here.

And finally, we'll look at the main carousel item loop:

<div
  ref={carousel}
  className="carousel-container relative flex gap-1 overflow-hidden scroll-smooth snap-x snap-mandatory touch-pan-x z-0"
>
  {data.resources.map((resource, index) => {
    return (
      <div
        key={index}
        className="carousel-item text-center relative w-64 h-64 snap-start"
      >
        <a
          href={resource.link}
          className="h-full w-full aspect-square block bg-origin-padding bg-left-top bg-cover bg-no-repeat z-0"
          style={{ backgroundImage: `url(${resource.imageUrl || ''})` }}
        >
          <img
            src={resource.imageUrl || ''}
            alt={resource.title}
            className="w-full aspect-square hidden"
          />
        </a>
        <a
          href={resource.link}
          className="h-full w-full aspect-square block absolute top-0 left-0 transition-opacity duration-300 opacity-0 hover:opacity-100 bg-blue-800/75 z-10"
        >
          <h3 className="text-white py-6 px-3 mx-auto text-xl">
            {resource.title}
          </h3>
        </a>
      </div>
    );
  })}
</div>

With our final JSX, we start with some classes that hide the overflow of any child items, display child items using flexbox, provide a basic gap between carousel items, and then add a bunch of scroll snap styles using Tailwind's handy scroll-snap facilities.

The scroll snap stuff isn't 100% necessary but it's recommended as it adds a nice little feel to how each item snaps into place when scrolled left to right, and helps prevent the scroll ending up weird half-way place between image items.

Next up we have a classic React pattern of looping through some sort of array with the .map() function and spitting out some repeated JSX for each iteration.

For each resource item we produce the following JSX:

<div
  key={index}
  className="carousel-item text-center relative w-64 h-64 snap-start"
>
  <a
    href={resource.link}
    className="h-full w-full aspect-square block bg-origin-padding bg-left-top bg-cover bg-no-repeat z-0"
    style={{ backgroundImage: `url(${resource.imageUrl || ''})` }}
  >
    <img
      src={resource.imageUrl || ''}
      alt={resource.title}
      className="w-full aspect-square hidden"
    />
  </a>
  <a
    href={resource.link}
    className="h-full w-full aspect-square block absolute top-0 left-0 transition-opacity duration-300 opacity-0 hover:opacity-100 bg-blue-800/75 z-10"
  >
    <h3 className="text-white py-6 px-3 mx-auto text-xl">{resource.title}</h3>
  </a>
</div>

This is what we saw in the early part of the article but with the Tailwind classes back in. What's happening here is that we have two blocks for each resource item.

The first block has a forced square width and height as well as centring any text. Inside of this, we have a link and an image. We're using an image-hiding pattern here that aids accessibility whilst giving us a tip-top UI. The image is given a src property and an alt tag, but is visually hidden from display. This allows screen readers to see the image but handles situations where the image is a wonky or irregular shape.

We attach the same image URL to the background property of the item and then set background styles via Tailwind to centralise and cover the full height and width of the item with the image.

The second block is another link that contains a heading level 3 element with the resource's title. Like its image block friend, it's given a full height and width, but 0% opacity so it's effectively 'hidden' from view (hiding in plain sight 😆).

When hovered on it's given a full opacity with a translucent background colour and contrasting white text. It's also positioned absolutely so we can display it on top of the image; the z-index value of 10 really helps here too.

This combination pattern of having some sort of image with some sort of hovered content appearing is very common. Although it's worth bearing in mind that for mobile purposes you'd likely want an alternative approach as the hover stuff won't work.

The carousel logic

Now for the fun part: making the carousel be more, well, carouselly...

Let's start with the component definition and initial variables:

const Carousel = () => {
  const maxScrollWidth = useRef(0);
  const [currentIndex, setCurrentIndex] = useState(0);
  const carousel = useRef(null);

We define the component and then set up some variables:

maxScrollWidth - we're going to store the carousel's total scrollable width in this variable once we finish rendering the component. We're using the useRef Hook from React here because it allows us to create a fixed or static value that won't change between renders. Important because the component is likely to rerender by clicking the prev/next buttons.
currentIndex - this is a simple state value that will keep track of what 'page' we're on. It'll help us later on to determine if we can move forward or backwards.
carousel - we're using the useRef Hook again, but this time to create a static reference to the underlying DOM element that is a div which houses the carousel contents. We'll need this to help work out when and how to scroll and get values relating to the carousel's width.

With the variables in place, let's look at the scrolling handlers...

const movePrev = () => {
  if (currentIndex > 0) {
    setCurrentIndex((prevState) => prevState - 1);
  }
};

For moving backwards, the movePrev function handles button clicks on the 'prev' button. We check to see if the currentIndex value is greater than zero and if it is, then we simply update the value in state to one less than the current value.

If we're already at zero then it doesn't make sense to go back anymore so the function short circuits out and doesn't do anything.

const moveNext = () => {
  if (
    carousel.current !== null &&
    carousel.current.offsetWidth * currentIndex <= maxScrollWidth.current
  ) {
    setCurrentIndex((prevState) => prevState + 1);
  }
};

When the 'next' button is clicked it's moveNext's time to shine. We're essentially doing the exact opposite of the movePrev function but things are a bit trickier. When moving backwards we just need to know when we hit zero. But when scrolling forwards we don't know how many times we can do that, it's not a hard limit defined by a single number.

Instead, we need to work out if the currently visible slice (i.e. width) of the carousel, times the current page, is going to be less than the maximum scrollable width of the carousel's content -- i.e. the carousel's total width, even that which isn't visible.

If it's going to be more than the max-width, it doesn't make sense to allow users to scroll anymore, so we don't do anything.

However, if our conditional statement passes, we do the opposite of movePrev and update the currentIndex value in state to one higher than its current value.

On their own, these button click handlers don't physically scroll the carousel contents, but we'll see in a moment how we can watch the value of currentIndex using the useEffect Hook to make that happen.

Next up, our isDisabled helper function:

const isDisabled = (direction) => {
  if (direction === 'prev') {
    return currentIndex <= 0;
  }

  if (direction === 'next' && carousel.current !== null) {
    return (
      carousel.current.offsetWidth * currentIndex >= maxScrollWidth.current
    );
  }

  return false;
};

Whilst the movePrev and moveNext click handlers will take care of actually triggering a scroll (or not), our users won't get any visual cues that they can or can't actually scroll. That's where our isDisabled function comes in.

On each render and rerender of the component, the buttons call out to the isDisabled function to see if their disabled attribute should be true, or false.

It accepts a direction argument and checks that first. You'll see that the conditional statements are very similar to the movePrev and moveNext ones. If we can't scroll left (previous) anymore, then it'll return true so that the button is disabled. Likewise, if we can't scroll right (next) anymore we'll also return true so the next button is disabled.

Failing all else, we'll just return false so that the buttons aren't disabled should the execution fall past our 'if' statements.

If a button is disabled, then Tailwind's disabled: styles will kick in and the user will find it much more obvious as to what they can and can't do.

Onto the part that makes the magic happen, the first useEffect Hook:

useEffect(() => {
  if (carousel !== null && carousel.current !== null) {
    carousel.current.scrollLeft = carousel.current.offsetWidth * currentIndex;
  }
}, [currentIndex]);

It's a deceptively simple little function that powers the scrolling of the carousel. The Hook accepts an array of dependencies that cause the code inside the Hook to fire when any of their values change.

In our case, we've added the currentIndex value as a dependency. So, when this value changes, say when we press the next or prev buttons, the code inside will run.

The first thing that happens is a null check to make sure that we've actually got a reference to the underlying carousel div element from our useRef Hook.

If we do, then we simply update the carousel's scrollLeft value to the carousel's currently visible width multiplied by the current index or page or slice of the content that we want to see.

As a simplified example of the maths involved here think of it like this...

If we have 10 items in our carousel each being 100 pixels wide, then we have a total scrollable width of 1000 pixels (10 items x 100 px).

However, because of the size of screen, the visible width of the carousel is only 250 pixels (remember, all the overflow is hidden by the CSS). This means we'll only be able to see two and a half items at any one time.

If we start from the initial view, 0 scroll left position, when we click 'next', the current index will be bumped up to '1'.

Now, we need to scroll the visible content currentIndex times the currently visible content width (1 x 250 px). Our carousel's new scrollLeft value will become 250 px and the carousel's contents will scroll over.

This will cause the contents of the carousel to scroll to the left and because of the smooth scroll and snap classes provided us by Tailwind, this happens nice and smoothly with a satisfying little 'snap' animation. Pretty neat!

There's just one last thing to take care of and that's a useEffect that fires on component render:

useEffect(() => {
  maxScrollWidth.current = carousel.current
    ? carousel.current.scrollWidth - carousel.current.offsetWidth
    : 0;
}, []);

We're passing in an empty array here, so this Hook only fires once, on the first component render. Its sole purpose is to get the carousel element's total scrollable content width minus the currently visible offset width value, and store this value in the maxScrollWidth ref value.

This will give us the bounding boxes that allow us to work out how much to scroll, how many times we can scroll before we run out of road, and help make the magic happen.

The final multi-item carousel component

The full carousel.jsx component looks like this:

import { useState, useRef, useEffect } from 'react';

// Data
import data from './data.json';

const Carousel = () => {
  const maxScrollWidth = useRef(0);
  const [currentIndex, setCurrentIndex] = useState(0);
  const carousel = useRef(null);

  const movePrev = () => {
    if (currentIndex > 0) {
      setCurrentIndex((prevState) => prevState - 1);
    }
  };

  const moveNext = () => {
    if (
      carousel.current !== null &&
      carousel.current.offsetWidth * currentIndex <= maxScrollWidth.current
    ) {
      setCurrentIndex((prevState) => prevState + 1);
    }
  };

  const isDisabled = (direction) => {
    if (direction === 'prev') {
      return currentIndex <= 0;
    }

    if (direction === 'next' && carousel.current !== null) {
      return (
        carousel.current.offsetWidth * currentIndex >= maxScrollWidth.current
      );
    }

    return false;
  };

  useEffect(() => {
    if (carousel !== null && carousel.current !== null) {
      carousel.current.scrollLeft = carousel.current.offsetWidth * currentIndex;
    }
  }, [currentIndex]);

  useEffect(() => {
    maxScrollWidth.current = carousel.current
      ? carousel.current.scrollWidth - carousel.current.offsetWidth
      : 0;
  }, []);

  return (
    <div className="carousel my-12 mx-auto">
      <h2 className="text-4xl leading-8 font-semibold mb-12 text-slate-700">
        Our epic carousel
      </h2>
      <div className="relative overflow-hidden">
        <div className="flex justify-between absolute top left w-full h-full">
          <button
            onClick={movePrev}
            className="hover:bg-blue-900/75 text-white w-10 h-full text-center opacity-75 hover:opacity-100 disabled:opacity-25 disabled:cursor-not-allowed z-10 p-0 m-0 transition-all ease-in-out duration-300"
            disabled={isDisabled('prev')}
          >
            <svg
              xmlns="http://www.w3.org/2000/svg"
              className="h-12 w-20 -ml-5"
              fill="none"
              viewBox="0 0 24 24"
              stroke="currentColor"
              strokeWidth={2}
            >
              <path
                strokeLinecap="round"
                strokeLinejoin="round"
                d="M15 19l-7-7 7-7"
              />
            </svg>
            <span className="sr-only">Prev</span>
          </button>
          <button
            onClick={moveNext}
            className="hover:bg-blue-900/75 text-white w-10 h-full text-center opacity-75 hover:opacity-100 disabled:opacity-25 disabled:cursor-not-allowed z-10 p-0 m-0 transition-all ease-in-out duration-300"
            disabled={isDisabled('next')}
          >
            <svg
              xmlns="http://www.w3.org/2000/svg"
              className="h-12 w-20 -ml-5"
              fill="none"
              viewBox="0 0 24 24"
              stroke="currentColor"
              strokeWidth={2}
            >
              <path
                strokeLinecap="round"
                strokeLinejoin="round"
                d="M9 5l7 7-7 7"
              />
            </svg>
            <span className="sr-only">Next</span>
          </button>
        </div>
        <div
          ref={carousel}
          className="carousel-container relative flex gap-1 overflow-hidden scroll-smooth snap-x snap-mandatory touch-pan-x z-0"
        >
          {data.resources.map((resource, index) => {
            return (
              <div
                key={index}
                className="carousel-item text-center relative w-64 h-64 snap-start"
              >
                <a
                  href={resource.link}
                  className="h-full w-full aspect-square block bg-origin-padding bg-left-top bg-cover bg-no-repeat z-0"
                  style={{ backgroundImage: `url(${resource.imageUrl || ''})` }}
                >
                  <img
                    src={resource.imageUrl || ''}
                    alt={resource.title}
                    className="w-full aspect-square hidden"
                  />
                </a>
                <a
                  href={resource.link}
                  className="h-full w-full aspect-square block absolute top-0 left-0 transition-opacity duration-300 opacity-0 hover:opacity-100 bg-blue-800/75 z-10"
                >
                  <h3 className="text-white py-6 px-3 mx-auto text-xl">
                    {resource.title}
                  </h3>
                </a>
              </div>
            );
          })}
        </div>
      </div>
    </div>
  );
};

export default Carousel;

Viewing the final demo

Here's the finished carousel code embedded via CodeSandbox and you can find a link to the sandbox here too:

How to use contact forms with headless WordPress and Next.js

Rob Kendal {{☕}} — Fri, 03 Sep 2021 20:08:20 +0000

If you’ve been following along with the series, you’ll have come across the previous posts:

In this article, part 4, we’re going to cover a key part of and good website: handling contact forms within a static website.

If you like this article, you’ll love the other helpful content I post on Twitter.Find me on Twitter @kendalmintcodeand say hi.

Contact forms and headless WordPress with Next.js

When it comes to allowing your visitors to send information to you via a contact form on your headless WordPress backend from a statically-generated front end, there are a few options, and I’m sure more are being added all the time.

However, in my experience, there are two solid, reliable, stand-out options to choose from:

Let’s take a look at these options in more detail.

Netlify Forms

Netlify Forms is yet another super powerful extension to the ever-popular Netlify platform. It works so easily and simply, using the familiar magic that only Netlify has.

It’s a cinch to set up with very minimal changes to your form HTML (or JSX in our case as we are dealing with React after all 😊), so let’s start with an example.

Wait! What if I don’t want to host things on Netlify? Good point. Netlify is awesome and I highly recommend it, but Vercel (the makers of Next) do the best job of hosting Next sites. That’s why we’re looking at the powerful Forms feature from Netlify first and then I’ll explain about the next best option.

Here’s a typical HTML form that you might have in your React app:

const MyContactForm = () => (
    <form name="contact" method="post">
    <p>
      <label>Your Name: <input type="text" name="name"/></label>
    </p>
    <p>
      <label>Your Email: <input type="email" name="email"/></label>
    </p>
    <p>
      <label>Message: <textarea name="message"></textarea></label>
    </p>
    <p>
      <button type="submit">Send</button>
    </p>
  </form>
);

Nothing too fancy there. To add Netlify’s form-handling powers to this then you need to do a few things:

Add in a hidden input with a form-name attribute and provide the name of your form.
Add in a netlify or data-netlify attribute to help Netlify identify the form.
Add in a data-netlify-honeypot attribute to help avoid unnecessary captchas for your visitors.

With these parts in place, the form now looks like this:

const MyContactForm = () => (
    <form
    name="contact" 
    method="post" 
    data-netlify="true" 
    data-netlify-honeypot="bot-field"
  >
    <input type="hidden" name="form-name" value="contact form" />

    {/* ...Rest of the form*/}
  </form>
);

Yeah, I know, it really is that simple. Depending on what React flavour your using (Next, Gatsby, etc.), you might need to add in a couple of additional small steps to make sure the form is wired up with Netlify. In this case you can read all the details on their blog post about integrating Netlify Forms in a React App.

You can also read more in the official Netlify Forms documentation.

WPGraphQL Send Email

Our next option is to use the popular WordPress plugin WPGraphQL Send Email. Before we dive into the setup and implementation, head over to the plugin’s page on WordPress.org and download and install it, or search for it directly in your WordPress site and add it there.

The WPGraphQL Send Email plugin wires up email sending capability into WordPress and exposes a GraphQL mutation inside of the WPGraphQL schema. This new sendEmail mutation enables you to send emails from your static front-end via WordPress.

You can integrate the sending capability with different providers too, such as SendGrid, Gmail, and Outlook/Office365. That part of the setup is a little beyond the scope of this article, but you’re free to use a simple SMTP server if you’d prefer — basically any service that can fire emails to other people.

Updating our Next.js site to use the WPGraphQL Send Email plugin

It’s not too difficult to plug all this into our Next site, but it does require a little more work than the Netlify Forms configuration.

We need to do two things here:

Add a new async API function to our /lib/api.js file.
Add a new contact page complete with a new contact form.

Add a new API handling function

OK, so first things first we need to add a new function to our /lib/api.js file. This new function will be a GraphQL mutation. Its sole purpose will be to pass our website visitor’s form data to our WordPress backend. Here, the Send Email plugin (now wired into the WPGraphQL system) will handle the physical sending of the email to whomever we’ve set up in there.

If you’re following on from the previous article on Using WordPress as a Headless CMS with Next.js then you can go ahead and open up the /lib/api.js file.

If you’re reading this article fresh with no existing codebase, then you can download a great starter kit project to wire up WordPress with Next.js on my GitHub profile. Check out the wordpress-next-starter repo to get started.

With the api.js file open and ready, add in the following new function:

export async function sendMail(subject, body, mutationId = 'contact') {
    const fromAddress = '[email protected]';
    const toAddress = '[email protected]';
    const data = await fetchAPI(
    `
        mutation SendEmail($input: SendEmailInput!) {
            sendEmail(input: $input) {
                message
                origin
                sent
            }
        }
    `,
    {
        variables: {
            input: {
                clientMutationId: mutationId,
                from: fromAddress,
                to: toAddress,
                body: body,
                subject: subject
            }
        }
    }
);

return data?.sendEmail;
}

What’s going on here in this new sendMail API function? Well, the official Send Mail plugin isn’t hugely helpful in explaining this on the plugin info page, but let’s go over what’s what.

First up, we have a function that accepts a subject, a body, and a mutationId which defaults to contact. The subject and body arguments are going to represent the subject line of the email we wish to send, and the body (HTML or otherwise) of the very same email. The mutationId field helps us to identify the name of the form we wish to send an email about.

We have a few variables at the start of the function that outline a ‘from’ address and ‘to’ address’, which will be attached to the email to identify who it’s from and where it’s going to. With the data variable, this is the main GraphQL mutation.

The mutation calls the sendEmail endpoint (this is the new endpoint exposed by the Send Email plugin) and is passed a SendEmailInput object. What it gives us back is a message, origin, and sent values. These are useful, particularly the sent value, for our front end to be sure that the form has been submitted successfully.

Further down the mutation in the supplied variables we just connect up all the incoming data and arguments we have so far, such as the body, from address and subject.

With that taken care of, let’s create a new page to house our contact form.

Add a new contact page and form

You could create a contact form anyway, or even create a reusable component that does the same trick, but for our purposes we’re going to create a good ol’ contact page with a form directly upon it.

We want this to live at the /contact route in our website, so in your Next.js project, under the /pages directory, create a new folder contact and a new file index.js.

With that done, populate the new index.js file with the following:

import Head from 'next/head';
import { useState } from 'react';
import { useRouter } from 'next/router';

import styles from '../../styles/Home.module.css';

const Contact = ({ menuItems }) => {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  const [message, setMessage] = useState('');
  const router = useRouter();

  const handleSubmit = async evt => {
    // we'll fill this in in a moment
  };

  return (
    <div className={styles.container}>
      <Head>
        <title>Contact us page</title>
      </Head>
      <main className={styles.main}>
        <h1 className={styles.title}>Contact us</h1>
        <hr />

        <form onSubmit={handleSubmit}>
          <div>
            <label className='label'>Your name</label>
            <input
              className='input'
              type='text'
              value={name}
              onChange={e => setName(e.target.value)}
              required
            />
          </div>
          <div>
            <label className='label'>Your email</label>
            <input
              class='input'
              type='email'
              value={email}
              onChange={e => setEmail(e.target.value)}
              required
            />
          </div>
          <div>
            <label className='label'>Your message</label>
            <textarea
              className='textarea'                  
              value={message}
              onChange={e => setMessage(e.target.value)}
              ></textarea>
          </div>

          <button>Send</button>
        </form>
          </main>
      </div>              
  );
};

export default Contact;

Looks quite long, but I always feel anything involving forms tends to look like this. Let’s break it down.

At the top, in the imports section, we’re bringing in useState from React, which we’ll use to store the entered values in our upcoming form fields. We also bring in useRouter and Head from Next which we’ll respectively use to route the user to another page when they’ve submitted the form, and to inject some SEO values in the page meta area.

Next we bring in the styles CSS module for the same generic styling we used before in the previous articles.

Now we’re onto the component itself. We set up a few useState variables, one each for our name, email, and message form fields we’ll be defining shortly:

const [name, setName] = useState('');
const [email, setEmail] = useState('');
const [message, setMessage] = useState('');
const router = useRouter();

We’re also initialising Next’s built-in useRouter() function so that we can redirect our visitors to a ‘thank you’ page when they’ve submitted the form.

We’ve created a handleSubmit() function that you won’t be surprised to hear will handle the submission of our form, which we’ll define next.

In the component’s JSX, after we add a bit of page scaffolding, title, SEO meta data, etc. you can see we return a pretty standard HTML form. We’re attaching the handleSubmit function to the form’s onSubmit event, and then everything else is straightforward HTML form business. The only thing of note here is that we connect each of the useState getters and setters to their corresponding form fields’ value attributes and onChange events.

So now, when people update the form fields’ values, their input values will be stored in our component’s state. Pretty neat!

With that out of the way, let’s fill out the handleSubmit function:

// ...other imports

// bring in the new sendMail API function
import { sendMail } from '../../lib/api';

const Contact = ({ menuItems }) => {
  // ...variables as before

  const handleSubmit = async evt => {
    evt.preventDefault();
    const emailContent = `
      Message received from <strong>${name}</strong>. 
      Their email address is <strong>${email}</strong>. <br />
      They'd like to know about...
      ${message}
    `;
    const data = await sendMail(
      'New message from website contact form',
      emailContent
    );

    if (data.sent) {
      // email was sent successfully!
      router.push('/contact/thanks');
    }
  };

  return (
        <div className={styles.container}>
            {/* ...rest of page and contact form */}
        </div>              
  );
};

export default Contact;

We’ve brought in out sendMail function from the API file, and filled out the handleSubmit function. Walking through the function, the process looks like this:

We call the evt.preventDefault() to stop the form from refreshing the page.
Next, we construct a string message, emailContent which will represent the body of the email we’re going to send from WordPress.
After this, we call our sendMail API function, passing in an email subject and our emailContent email body, and await the return.
Once the function returns, we check the sent property and if it’s successfully sent it’ll be true, which means we can redirect our visitor to the /contact/thanks page via Next’s built-in router.

We haven’t actually created the /contact/thanks route as it’s outside the aim of this article, but you could redirect your visitor’s anywhere at this point, an external URL, another internal page, or even not route them anywhere and just display a simple ‘thank you’ message.

Note : you could abstract some of the email body creation into a separate function in a utility/helper library to build up a suite of rich HTML email templates if you wanted. We’ve just opted for a plain ‘someone sent you a message on your website’ situation here for simplicity.

Sending contact forms with WordPress and Next.js

And that’s it! With very little effort, we’ve managed to wire up our WordPress backend with our detached, Next-powered front-end to facilitate sending contact forms from our static sites via the handy WPGraphQL Send Email plugin.

Helpful links

Here’s a reminder of the links used in this article:

Netlify
Netlify Forms and the official Forms documentation
WPGraphQL Send Mail
Part one of the series: Configuring WordPress as a Headless CMS with Next
Part two of the series: Using WordPress as a Headless CMS with Next
Part three of the series: Create a Next.js RSS feed for your static website

React, Angular and Vue compared, which should you learn in 2021?

Rob Kendal {{☕}} — Mon, 07 Jun 2021 08:08:20 +0000

One of the most common questions I get as a coding mentor when it comes to moving on from learning the basics of HTML/CSS and JavaScript is:

which is the best JavaScript framework to learn, right now, in 2021? Should I learn React, Angular or Vue?

I recently released a brand-new course for React students, The Beginner's Guide to Real-World React, where you can learn how to go from complete React beginner to building realistic UI applications using the React framework. Hot on the heals of the course release, I thought it would be good time to answer this very important question.

Let's dive in!

Similar frameworks and their comparisons

There are many JavaScript libraries, frameworks, tools, projects, and platforms out there that help solve developers’ problems, help them build user interfaces, and ship excellent products faster. When it comes to the building user interfaces part, arguably the most popular libraries out there are Angular, VueJS, and ReactJS.

Much like React (which I'm a huge fan of) both Vue and Angular are concerned with empowering developers to build complex user interfaces in a modular way, breaking down parts of those interfaces into component parts.

Looking at the search data from Google Trends, you can see that Vue has been steadily gaining interest over the past few years, only dipping over the course of late 2020. React has increased dramatically, whilst Angular has declined over the same time frame. Both React and Angular have dropped off in search interest over the course of late 2020, with React gaining more popularity once more towards present day (June 2021)

Comparing Angular, React and Vue frameworks

Let's take a quick tour of each of these three big players in the front-end web application building space and see if we can help you determine which of the popular JavaScript frameworks you should be learning in 2021.

React

React came onto life in 2013 and has gone from strength to strength. React is more of a library than a complete framework and it has many missing pieces of the overall development puzzle (this is one of the things The Beginner's Guide to Real-World React aims to address!).

React is declarative, meaning it allows us to break down our complex user interfaces into smaller, bite-sized pieces of functionality that operate on their own; managing their state, given some sort of input data referred to as props. These smaller components can be brought together as building blocks for larger, more complex user interfaces that interact via passed in data and events.

Benefits

Small and relatively lightweight as libraries go.
Declarative in nature; you can write your UI as you want it to be rendered.
Shallow learning curve, especially when it comes to learning the essentials.
Works a lot on an 'opt-in' fashion where you can adopt as much or as little as you need.
React is very unopinionated, it gets out of your way.

Drawbacks

Some library differences can cause confusion and add to the learning curve (e.g. classes vs. function components).
React is very unopinionated, you're going to have to fill in the blanks to add things like navigation to your app.
It's made by Facebook -- this could be a deal-breaker for some developers.
Because of its free and easy approach, there aren't a lot of best-practices or clear guidelines around developing with React.

Vue

VueJS came onto the scene around 2014 and was developed by a former Google employee Evan Yu. Vue is a progressive JavaScript framework, similar to React, and has a rich ecosystem of additional libraries and plug-ins to enable additional functionality.

Benefits

Empowered HTML: Vue has a lot of similarities with Angular in the way that it decorates HTML blocks within its components.
Detailed documentation: one of the best features of Vue is the hugely detailed and informative documentation that helps developers at either end of the experience scale.
Ease of integration: whether you’re building single-page applications (SPA’s) or more complex applications, Vue’s smaller, interactive parts mean it can be integrated into existing infrastructure without affecting the wider * system.
Large scaling: Vue can be used to develop pretty large, reusable templates to power very complex apps.
Small code footprint: Vue weighs in at around 20KB keeping its size small, but also aiding in increasing its speed and performance.
Short learning curve

Drawbacks

Lack of support and resources: whilst rising in interest and boasting a loyal and growing community, Vue has the smallest market share and so naturally has limited resources and solutions out there for budding developers or those seeking answers.

Angular

Angular (formerly AngularJS, which is a very different beast), is a fully-fledged framework released back in 2009. It boasts a very mature framework that handles everything you need to build rich, data-driven user interfaces right out of the box. It offers an MVVM (Model, View, View Model) approach to development structure that separates the working parts into their respective areas of responsibility.

Benefits

MVVM structure: this allows developers to work on the same area of the app without stepping on colleagues’ toes. However, the MVVM approach is not as intuitive to those starting out or those unfamiliar with this particular project structure.
Two-way data-binding: this enables singular behaviour within the app, reducing the risk for errors.
Dependency injection of the required features that the current components depend on.
Deep coupling with TypeScript: including excellent TypeScript support.
Very detailed documentation and guides
Mature ecosystem: similar to the documentation, Angular is widely used and has a large ecosystem of resources, guides, help, and advice for just about any situation you’ll come across.
Opinionated approach: even down to the structure and architecture to make sure your project can scale well.

Drawbacks

Steep learning curve: Angular is very complex and has an equally steep learning curve which is a big barrier to entry, especially for new developers
Migration: is often a problem when moving from older versions to new
Deep coupling with TypeScript: yes, this is also a benefit, but TypeScript is not widely adopted by new developers and adds yet another few degrees to an already steep learning curve

When it comes to React, Angular and Vue, which framework is best?

This is really a deceitful question as it pits each framework against one another and it really boils down to opinions and preference. There are many solid reasons to choose any of these three frameworks, or indeed, none at all.

Remember, that any library, framework, platform, language, design, pattern, whatever, they’re all just tools.

In the same way that you wouldn’t use a hammer to unscrew a bolt, sometimes it’s about finding the right tool for the job. When you have a choice of hammers, then it can be a simple as ‘I prefer this one over that one’. And it’s just as easy to write bad code in a good library.

Should I learn React, Angular or Vue to get a job?

If you're coming here with the angle of looking for a job then the best advice is to take a look at the local job market where you are. For example, here in Yorkshire, we have the two cities of York and Leeds, the latter being a huge tech-hub for the North of England.

It’s very diverse as tech goes with a wide variety of technologies, languages and sectors that you can choose to apply for roles within. In terms of tech stack, the job market in this part of the world is very React and Angular dense at the front-end, with PHP and .NET forming the largest part of the server-side technologies.

So, if I were in the market for a job, I’d be focusing on those languages and tech-stack.

What about other frameworks, which should I learn?

There are, of course, about as many user interface building libraries, frameworks, and platforms as there are hairs on your head, with more popping up all the time. The big question you should be asking is "which one is right for me, my team, my project(s)?".

You might not have much of a choice in this, depending on where you choose to work and what projects you choose to work on. This article is really about comparing the good and bad parts of the three heavy hitters in the market today, midway through 2021.

If you’re interested in looking at other front-end, UI-building libraries and frameworks then some other popular choices include:

Preact, a tiny alternative to React that operates in a very similar way.
Svelte, a very popular alternative to other interactive UI building languages that shifts to a compiled step (as opposed to React and Vue that do work in the browser).
Ember, a very robust and battle-tested JS framework for building modern web applications.

The Beginner's Guide to Real-World React

Rob Kendal {{☕}} — Thu, 13 May 2021 07:02:05 +0000

🚨 HUGE ANNOUNCEMENT ALERT 🚨

My shiny new course, The Beginner's Guide to Real-World React is live 🥳

If you've been wanting to learn React or struggling to get going then this course is a perfect place to start!

In the course you'll take a deep dive into core React concepts as you learn more about how React works, how you can use it to build complex web applications, and how to combine it with third-party libraries and frameworks to 'join the dots' and gain a detailed understanding of how you might use React in a real world setting.

You'll get:

8+ hours of video
50 lessons
loads of practical React advice
...and more

Great for beginners, the link's below with 50% off for a limited time

Check it out here, on the Newline course page.

The Front End: S3-E2 - Matt Studdert

Rob Kendal {{☕}} — Sun, 21 Mar 2021 15:01:21 +0000

In a very exciting second episode we have the one and only Matt Studdert, the founder of Frontend Mentor, a learning resource used by over 100,000 budding developers to sharpen their skills.

Listen to the brand new episode here:

Apple Podcasts > https://podcasts.apple.com/gb/podcast/the-front-end/id1499349107
Pocket casts > https://pca.st/osul2zsa
Spotify > https://open.spotify.com/show/4GuAxptrtY8Es5iHwp09dT
Anchor > https://anchor.fm/the-front-end

In this episode

After being recommended as a guest to the show by several twitter peeps, we’re so pleased to welcome Matt Studdert. Matt is a fellow UK developer and founder of the hugely popular Frontend Mentor, a coding skills levelling up platform used by close to 100,000 people to hone their skills in front end development.

Matt hails from a background in fitness and personal training and made the leap to dev life, and shares a passion for helping others get into development. He’s going to share his story and give us some tips on how and where to start with learning to be a developer.

Listening direct

Want to listen directly from here?

Want to be a guest or sponsor the show?

We're always happy to take requests for guests to talk about a range of different development topics from careers to origin stories, learning and professional growth, frameworks and more.

Similarly, we're looking for sponsors to fill promotional slots within the show.

You can find out more here:

Thanks for listening!

The Front End: S3-E1 - Brian Rinaldi & Raymond Camden

Rob Kendal {{☕}} — Mon, 08 Mar 2021 07:14:51 +0000

🚨 NEW SEASON ALERT 🚨

In this very first episode of the brand new season 3, we talk to Brian Rinaldi, a dev advocate from StepZen, and his partner in crime, Raymond Camden, a lead developer evangelist for HERE.

Listen to the brand new episode here:

Apple Podcasts > https://podcasts.apple.com/gb/podcast/the-front-end/id1499349107
Pocket casts > https://pca.st/osul2zsa
Spotify > https://open.spotify.com/show/4GuAxptrtY8Es5iHwp09dT
Anchor > https://anchor.fm/the-front-end

In this episode

This Jamstack-loving pair have co-authored a book called The Jamstack Book, which is published by Manning and dives deep into the Jamstack and helps you build up a portfolio of Jamstack-architectured sites including a full-blown e-commerce store.

Now, as a very special reward for you lovely listeners of the show, Manning have been kind enough to offer some free copies of the book and some permanent discount codes so you can snap up a copy for yourself and learn all about the Jamstack.

Grabbing your copy of The Jamstack Book (with discounts)

Pop along to this link to grab your own copy of the book,

The Jamstack Book

and use the code podfrontend21 to get a MASSIVE 35% off!

Listening direct

Want to listen directly from here?

Want to be a guest or sponsor the show?

We're always happy to take requests for guests to talk about a range of different development topics from careers to origin stories, learning and professional growth, frameworks and more.

Similarly, we're looking for sponsors to fill promotional slots within the show.

You can find out more here:

Thanks for listening!

The Front End: S2-E10 - Hassan El Mghari

Rob Kendal {{☕}} — Mon, 14 Dec 2020 07:18:26 +0000

🚨 SEASON FINALÉ 🚨

For this final episode in the season Hassan El Mghari joins us to share his incredible journey from high-school student running multiple gaming communities totalling almost a million users, founding a gaming marketing company, to pursuing a CS degree and learning full stack development.

Listen to the brand new episode here:

Apple Podcasts > https://podcasts.apple.com/gb/podcast/the-front-end/id1499349107
Pocket casts > https://pca.st/osul2zsa
Spotify > https://open.spotify.com/show/4GuAxptrtY8Es5iHwp09dT
Anchor > https://anchor.fm/the-front-end

In this episode

Hassan El Mghari is currently studying for a CS degree at Drexel. However, whilst in high-school he successfully started a games marketing business, UltraShock Gaming.

Hassan talks lessons learned, how to learn in public and the power of long-game effort.

Listening direct

Want to listen directly from here?

Want to be a guest or sponsor the show?

We're always happy to take requests for guests to talk about a range of different development topics from careers to origin stories, learning and professional growth, frameworks and more.

Similarly, we're looking for sponsors to fill promotional slots within the show.

You can find out more here:

Thanks for listening!

The Front End: S2-E9 - Rob Kendal Q&A

Rob Kendal {{☕}} — Mon, 30 Nov 2020 08:33:30 +0000

🚨 NEW EPISODE ALERT 🚨

For the penultimate episode (9) of season 2, I'm hosting a special 1-2-1 show where I answer some of your burning questions on front end development, careers, and more.

Listen to the brand new episode here:

Apple Podcasts > https://podcasts.apple.com/gb/podcast/the-front-end/id1499349107
Pocket casts > https://pca.st/osul2zsa
Spotify > https://open.spotify.com/show/4GuAxptrtY8Es5iHwp09dT
Anchor > https://anchor.fm/the-front-end

In this episode

I'm Rob, a freelance front end developer, Shopify Partner, and lover of WordPress, the Jamstack, and helping people learn to code.

I'm going to answer burning developer questions such as:

Should I learn React or Vue?
How long before I start looking for a job?
How do I start blogging and creating content?
How can I get into freelancing?
...and many more!

Listening direct

Want to listen directly from here?

Want to be a guest or sponsor the show?

We're always happy to take requests for guests to talk about a range of different development topics from careers to origin stories, learning and professional growth, frameworks and more.

Similarly, we're looking for sponsors to fill promotional slots within the show.

You can find out more here:

Thanks for listening!

Things I wish I'd known as a junior developer

Rob Kendal {{☕}} — Fri, 20 Nov 2020 07:44:55 +0000

I've been a developer for over fifteen years and I've loved almost every minute of it. I can't imagine doing anything different but there are moments when I think back to starting out and how different the development landscape was, especially when it comes to learning how to code.

I'm really not that old, but things in the tech world move fast and there weren't as many resources around to help people get into frontend development and learn how to build something from HTML, CSS, JavaScript, etc. There wasn't as many great communitys like Dev or Hashnode or WeStryve, not learning platforms such as Free Code Camp or The Odin Project.

So a lot of my early career felt like fumbling around for me, picking up everything I could from senior developers, hoping that they knew what they were doing, reading as many books as a I could and practicing my craft.

It's fair to say there were quite a few things I wish I'd known a lot earlier in my career that could have helped me progress faster or just develop both my coding skills, as well as my more complimentary skills, such as dealing with people or learning how to learn.

Hopefully, with this article I can distill what I've learned to date and share some things to watch out for and take on board to help you with your career as a frontend developer.

(Pssst -- If you like this article, come find me on Twitter where I post regular helpful content every day)

Start writing a blog

This very blog you're reading now (whether it's on my own website or my Dev or Hashnode accounts) has grown quite popular and that's great. But I really wish I'd started much earlier and written more frequently.

Honestly, blogging is such a great way to cement what you've learned as you're learning it. You absolutely do not have to be a developer with X years in the business, nor do you have to be an expert.

All you need is a curios mind and to think about writing for your past self: write the article you wish you'd had on the subject.

As a bonus, if you fix something particularly tricky, you'll be able to refer back to your own article to help you solve it in the future!

My friend Catlin Pit has a couple of recommended articles on blogging too:

Should you start a blog as a developer
How to start a blog - a common question after 'what do I write about?'

Ask more questions!

This seems obvious, but in my experience it's really not. A lot of developers, especially those early on in their careers are easily intimidated by more experienced devs or just those that have been around longer, and this can prevent them from speaking up.

But you know what? That's how you learn: you ask questions, you get answers (and, back to the previous point, you now have content for a blog article!).

Never be afraid of asking questions, especially if you're stuck on something. There are no stupid questions, but I'm not going to lie, you will at some point come across arrogant or unhelpful people who will make you feel otherwise. My advice, ignore them and find more open and helpful people.

Be honest on what you're passionate about

If you love what you do and are fortunate enough to get to do that regularly, especially as a full time career then you've hit the jackpot.

However, I see a lot of people stuck in places and in roles that they just don't have the passion or drive for. I'm well aware that not everyone is fortunate enough to be able to pick and choose, but as developers we have long held a valuable position in the job market where there are more jobs than there are developers.

But this is really about having a truthful discussion with your inner dev and being both honest about what you really enjoy doing/not doing, and realistic about how to start a role doing this.

For example, if you really really really don't like PHP, then take care when interviewing or seeking out roles in development agencies where WordPress is heavily featured.

This advice is especially true for those seeking, perhaps, their first development roles. Be honest and candid about what's right for you and (if you're able to), don't just jump at the first opportunity that comes your way.

The more you can discover what direction you want to travel, the better aligned you'll be down the line in your career.

With all of the above said, please don't put pressure on yourself to decide too early. Sometimes you have to experience what you don't want to know what is right for you.

Get a coding mentor

I was supremely fortunate to have worked with some amazing developers back when I started. They were experienced, knowledgable, helpful and humble and really took me under their wing. I'll never be able to thank them enough.

Therefore, I'd highly recommend getting yourself a mentor to help with your development journey.

This is different from a teacher or tutor (although there is overlap at the edges of the roles): a mentor is a guiding light to help give you focus and direction, to answer questions and point you along the right path for your particular journey.

I'd recommend taking a look at Coding Coach or my very own mentorship programmes to find a mentor that's right for you.

Mentor others

Following on from the last point, you too can be a mentor and again, you don't have to have coded for decades or be an absolute expert.

Think about where you are on your journey and how far you've come. Even if you're 6-8 months into learning to code, there are people only 1-2 weeks into theirs; these are the people you can definitely help out.

That said, if you are quite experienced, then all the more reason to help someone else who's just starting out.

Become the guide you wish you'd had when you started

It's rewarding beyond measure, and a win win situation: someone getting started is helped and guided, and you learn so much in the process, believe me.

You don't get what you don't ask for

I'm from Yorkshire in the UK and there's a saying in this North East part of the world: Shy bairns get nowt.

In essence we're really saying that 'you get nothing by keeping quiet'.

It's easy to look at seemingly successful developers and popular Twitter personas and assume that everyone has lucky breaks and opportunity just falls from the sky.

To be honest, this does happen to a small number of people, but most of the successful people you'll know are a combination of trying (a lot), keeping their eyes open for opportunities and only a little sprinkle of luck.

Most of the time it's about asking for what you want. Now I'm not suggesting you just go kicking your boss' door in a demanding a raise, but in all seriousness, if you think you deserve a pay rise, prove it and then ask for it!

Want to switch up your career? Ask about training programs at your current workplace. Want to talk to someone on LinkedIn about their career? Ask them.

The worst that will happen is you get a 'no'. In which case, time to move on and try something else.

Keep track of all your wins

This is a big one for me. It's very easy as a human to skew towards the negative. Even if you've just launched five features on a product used by millions, I would bet that it's that single tiny error that happened that you'll be thinking about, right?!

I keep a notebook of little victories and compliments I've received and look through them from time to time, especially when the imposter syndrome kicks in from time to time.

It's not about ego or vanity, but it's about celebrating your victories and remembering how far you've come.

You don't have to know everything

The world of deveopment is HUGE. I mean seriously almost infinite. Between languages, frameworks, patterns, platforms, frontend, backend, the list goes on.

When you're starting out there can be an overwhelming urge to have to know everything all at once. But I'm here to tell you that you don't need to know everything and, in reality, you can't or won't ever know it all q-- the landscape is just too vast.

Of course, as a frontend developer starting out, I'd recommend focussing on the three core pillars of HTML, CSS, and JavaScript, but once you're getting into the swing of things, start to add bits and pieces to your knowledge depending on what takes your fancy.

Senior doesn't mean encylopedia

Just because someone is a senior developer or an architect or principle, or has been programming for 100's of years, does not automatically make them the all knowing beasts you think they may be.

I'll let you into a secret: I've been developing in a fullstack fashion for over fifteen years and I still have to look up some of the most trivial snippets of code; I still miss semicolons out of things and I still make mistakes.

Sure, I know a lot about a lot, but there's oceans of knowledge I haven't even sailed upon. Just because people have been around the block doesn't directly equate to an infallible, all-knowing knowledge. Neither does it mean they're always automatically right or know better.

The point I'm driving at here is that just because you're less experienced or starting out doesn't mean your ideas are less valuable or that you have less to contribute.

It's also why adopting a life long approach to learning is so important as a developer.

Titles don't really mean much in the long run

Another thing to bear in mind is that some people get caught up in a title race and it's easy to think that becoming a 'principle developer' or 'lead architect' is the end goal. Yes, titles and recognition are nice and there's money and rewards that come with more senior titles, but they don't always reflect the abilities of the holder nor

I'm not saying that it's not OK to have 'become a lead developer' as a goal, but don't set your standards by the titles that you, or others, hold. It's your attitude, actions, and what you contribute to the development community that will ultimately shape your legacy.

Networking is essential!!

It really is who you know not always what you know.

I wish I'd spent more time making connections with other developers, recruiters, leaders, and makers on social media, in real life. I think I've made up for it over the years, but had I started sooner, who knows what doors it could have opened up.

Make yourself a Twitter profile and register on LinkedIn. These are both excellent platforms for connecting with your fellow devs and growing your network. It's not about a popularity contest, but it'll help you with a number of areas in your career:

Finding a new job.
Starting a freelance business.
Launching a product or service.
Selling content, ebooks, courses, and more.
Make new friends.
Helping other to learn.
Contributing to open source.

And it doesn't have to involve hours and hours of work, but just regular little interactions with people, making connections, being helpful and honest, being yourself. Over time, your network will grow and you'll get as much out of it as you give.

Ignore the gatekeepers

As with all life, you're going to come across people who, for whatever reason, just aren't great. There's a lot of gatekeeping in a lot of industries, but it's especially rife in the tech world.

You can avoid a lot of it by just not engaging, and I'd strongly suggest that you do avoid as much as possible. I come across a lot of developers who have been put off before they've even started because of trolls, haters, negative attitudes, condescension, and don't get me started on how women in tech can be treated.

Development is one of those few things in life that's truly open for everyone. It's about your mental attitude and looking at problems, breaking them down, solving for others. Everything else is just tools, time, practice and approach.

I don't like CSS-in-JS, but you know what, it's a valid approach and if it helps some people build something awesome for others then that's OK by me.

Sure, there's better ways of doing things and some tried and tested approaches that work smoother than others, but a lot of development is opinions, nothing more.

So don't let others tell you you can't or let them intimidate you of course. Similarly, don't shame people when they share something of theirs.

Recruiters are both the devil and angels in disguise

I love recruiters. Well, some, recruiters. In fact, I owe a lot of my success to the good ones.

If you want to get your foot in the doors of places you might not ordinarily be able to, get in touch with some recruiters and share with them your career aspirations. This is an essential part of networking for me.

It's increasingly important as a junior developer starting out to grow a connection base that includes at least a handful of trusted recruiters that take a genuine interest in you. They good ones will put the work in, take the time to get to know you and your skills and really talk you up to their clients (the employers).

Don't be put off by the chancers, the glorified mobile phone salesmen, and the ones that don't have your interests at heart.

Everyone feels like imposter

I have an article on fighting imposter syndrome as a developer which is worth a read, but there's bound to be a few points in your career where you'll feel down, feel a little worthless like your contributions don't matter, and wonder what the hell you're doing with your career.

That's OK. That's normal and it's more common than you think. In fact, it's very common in high-functioning, intelligent people. That feeling of not belonging, where you're simply blagging it and faking it and people will eventually find you out.

This is where little tips like talking about it helps, as does keeping that accomplishments journal we talked about earlier. Believe me, everyone suffers from it here and there and I'm no exception.

Just remember that you can combat it and you should push ahead with your goals regardless.

DEV Community: Rob Kendal {{☕}}

Exciting news for remote dev job seekers

Build a restful Node API server using JSON and TypeScript

1. Node API project setup

Installing dependencies and build scripts

Configuring TypeScript

Adding some basic user data

2. Building the new server.ts file

The imports

Setting up the Express router

Configuring CORS

Adding in the routes and handling errors

Starting the server

2a. Module aliases

3. Mapping the routes

Adding user routes to our main router

4. Creating our controller

User types for TypeScript

5. Testing the API server

6. Extending the API server with CRUD

Enjoy your fully functional Node-based API server

How to fix 'Property does not exist on type Window in TypeScript' error

Discovering the 'Property does not exist on type Window in TypeScript' error

Identifying the problem

Fixing the 'Property does not exist on type Window in TypeScript' error

Wrapping up

How to build a multi-image carousel in React and Tailwind

What we'll be building

Tools used

Building the multi-image carousel in React

Carousel data

Basic styles

The multi-item carousel component

The carousel JSX

The carousel logic

The final multi-item carousel component

Viewing the final demo

How to use contact forms with headless WordPress and Next.js

Contact forms and headless WordPress with Next.js

Netlify Forms

WPGraphQL Send Email

Updating our Next.js site to use the WPGraphQL Send Email plugin

Add a new API handling function

Add a new contact page and form

Sending contact forms with WordPress and Next.js

Helpful links

React, Angular and Vue compared, which should you learn in 2021?

Similar frameworks and their comparisons

Comparing Angular, React and Vue frameworks

React

Benefits

Drawbacks

Vue

Benefits

Drawbacks

Angular

Benefits

Drawbacks

When it comes to React, Angular and Vue, which framework is best?

Should I learn React, Angular or Vue to get a job?

What about other frameworks, which should I learn?

Further reading and other resources

The Beginner's Guide to Real-World React

The Front End: S3-E2 - Matt Studdert

In this episode

Listening direct

Want to be a guest or sponsor the show?

The Front End: S3-E1 - Brian Rinaldi & Raymond Camden

In this episode

Grabbing your copy of The Jamstack Book (with discounts)

Listening direct

Want to be a guest or sponsor the show?

The Front End: S2-E10 - Hassan El Mghari

In this episode

Listening direct

Want to be a guest or sponsor the show?

The Front End: S2-E9 - Rob Kendal Q&A

In this episode

Listening direct

Want to be a guest or sponsor the show?