Ever wondered if it’s ok to have your API key bundled with the frontend, public for anyone who uses your app to see?
You know you should never put secrets in the UI. But then you see people bundling their keys with the UI all the time (Firebase API key, anyone? 😀)

So how can you tell what to do in your case?
This article aims to shed some light on how you can decide for yourself.

Be aware that there are no secrets in the frontend

Before moving on to more specific advice, it’s good to get one thing clear first: there are no secrets in the UI.

Your frontend, after being compiled, is really just a bunch of HTML, Javascript and CSS files.
And if there is any key that the UI needs, it’s usually just hardcoded as a variable in the Javascript code.
This means that someone can inspect all the global variables your have in memory and track down the key.

But they don’t usually need to go such lengths - the keys are usually used to call APIs, so it’s enough to open the Network tab to see what request parameters or request headers are sent and figure out the keys!

Consider whether your API keys can be public or not

In general, you never want to share your API keys. This means you should only use your keys from the backend, where they are not accesible publicly.

However, there are some exceptions to this.

Some keys don’t give access to any resources, but instead act as an “ID” that associates you or your application to a certain user account. A good example of this is the Firebase API key - the docs explicitly say it’s ok to include this key in your code:

Usually, you need to fastidiously guard API keys (for example, by using a vault service or setting the keys as environment variables); however, API keys for Firebase services are ok to include in code or checked-in config files. source

Another exception could be for keys that only give access to public resources. Even if there is a risk that the key is compromised, the risk is very low - if anyone can get their own key for free, why would they steal yours? A good example of this is the Movie Database API - it’s not ideal to have the key public, but the risk is also very low.

Lastly, it could be ok to have your key in the UI if you setup some extra guards in place. Two common strategies are to only limit the usage of the key to requests coming from a certain domain and to setup restrictive quotas to prevent brute force attacks.

Don’t commit your secrets to git

If you’ve decided it’s ok to use your key in the frontend, don’t just include it in your code! Instead, extract it as a build-time environment variable.

This will allow you to configure the key based on different environments (staging/production etc.) and also make it a bit harder for someone to steal.

To achieve this, you’d usually have a file containing the app configuration (usually called .env), that you don’t commit to git (by ignoring it in your .gitignore file) and whose values you can access in your app as Node environment variables - process.env.SOME_API_KEY.

If you’re using Webpack, you can setup dotenv and the dotenv-webpack plugin to get this to work. If you’re using CRA, you get it out of the box.

Conclusion

I hope you found this overview useful. Do share your thoughts in the comments below if you have any feedback or questions!

In a previous article, I went over how you can setup a simple React app with just Webpack and Babel. But what if you also want to enable Typescript for your project?

This article goes over how to add Typescript support to a simple React + Webpack project.

Step 1: Install Typescript and type definitions

The first step is to just install Typescript:

npm install typescript --save-dev

Then, it helps to install the type definitions for all the libraries you already use. Usually, this would be:

npm install @types/node @types/react @types/react-dom @types/jest --save-dev

Step 2: Configure Webpack

For Webpack to be able to process Typescript files, we will first need to install a custom loader.

There are several available, but we’ll use ts-loader for our setup:

npm install ts-loader --save-dev

Next, we need to tell Webpack to process TS files as well. For this, we can update the webpack.config.js file to also support ts and tsx extensions:

// webpack.config.js

{
  // ...,
  module: {
    rules: [
      // `js` and `jsx` files are parsed using `babel`
      {
        test: /\.(js|jsx)$/, 
        exclude: /node_modules/,
        use: ["babel-loader"],
      },
		// `ts` and `tsx` files are parsed using `ts-loader`
      { 
        test: /\.(ts|tsx)$/, 
        loader: "ts-loader" 
      }
    ],
  },
  resolve: {
    extensions: ["*", ".js", ".jsx", ".ts", ".tsx"],    
  },
}

Step 3: Configure Typescript

The Typescript compiler supports several options for how to treat the code, which are defined in a tsconfig.json file in the root of the project.

Let’s create one for this project as well:

// tsconfig.json
{
  "compilerOptions": {  
    "jsx": "react-jsx",
  }
}

For the purpose of this tutorial, I just added the minimal settings that are required for the React + TS + Webpack integration, but you can learn more about all the options available in the official documentation.

Step 4: Start using Typescript

If you already have some Javascript files in your project, now is a good time to change their extensions from js to ts and from jsx to tsx!

Then, restart the app and you should see everything still working ✨

Check out the completed repository at https://github.com/reactpractice-dev/basic-react-ts-boilerplate.

Let's do that!

At the end of this tutorial, you'll have a Docker container running your app that you can deploy as you see fit 👌

We're going to start from an existing app - a barebones app, using just Webpack and React. Find the starter code on Github or follow a step by step tutorial to setup the app.

Step 1: Building a Docker image

To build a Docker image, we want to copy all the source files inside the container, build the project (also inside the container) and then serve the build folder.

Let's start by ignoring the files that we never want to copy to the docker image. For this, we'll create a .dockerignore file in the root of the project:

// .dockerignore
node_modules
build

Next, let's define our Docker container by creating a Dockerfile in the root of the project:

// Dockerfile

# ==== CONFIGURE =====
# Use a Node 16 base image
FROM node:16-alpine 
# Set the working directory to /app inside the container
WORKDIR /app
# Copy app files
COPY . .
# ==== BUILD =====
# Install dependencies (npm ci makes sure the exact versions in the lockfile gets installed)
RUN npm ci 
# Build the app
RUN npm run build
# ==== RUN =======
# Set the env to "production"
ENV NODE_ENV production
# Expose the port on which the app will be running (3000 is the default that `serve` uses)
EXPOSE 3000
# Start the app
CMD [ "npx", "serve", "build" ]

Notes

• Using `alpine` flavour of an image (e.g. `node:16-alpine` instead of `node:16`) will give you a smaller image size
• Check what the latest LTS Node version is and use that Docker image. At the time of writing of this article, it was Node 16
• For simplicity, we're just serving the app with npx serve for now. Step 2 will add nginx, so stay tuned!

Ok, let's build the Docker image and run it, to make sure everything works.

# Build the Docker image for the current folder 
# and tag it with `dockerized-react`
docker build . -t dockerized-react

# Check the image was created
docker images | grep dockerized-react

# Run the image in detached mode 
# and map port 3000 inside the container with 3000 on current host
docker run -p 3000:3000 -d dockerized-react

Now open the app at http://localhost:3000 - you should see "Hello from React" 😀

Step 2 - Serve the app through nginx

While serving the app with serve is ok for small apps, it's common to just use nginx to serve the static files, so let's set that up as well.

Also, while we're at it, we'll separate the "build" and "run" steps of creating the Docker image by taking advantage of Docker image layers. This allows us to run the build in a node image and server the app using an nginx image.

To begin, let's create an nginx.conf file in the root of the project:

// nginx.conf

server {
  listen 80;

  location / {
    root /usr/share/nginx/html/;
    include /etc/nginx/mime.types;
    try_files $uri $uri/ /index.html;
  }
}

Next, let's update the Dockerfile to with separate layers and serving the app with nginx:

FROM node:16-alpine as builder
# Set the working directory to /app inside the container
WORKDIR /app
# Copy app files
COPY . .
# Install dependencies (npm ci makes sure the exact versions in the lockfile gets installed)
RUN npm ci 
# Build the app
RUN npm run build

# Bundle static assets with nginx
FROM nginx:1.21.0-alpine as production
ENV NODE_ENV production
# Copy built assets from `builder` image
COPY --from=builder /app/build /usr/share/nginx/html
# Add your nginx.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf
# Expose port
EXPOSE 80
# Start nginx
CMD ["nginx", "-g", "daemon off;"]

Now, the final Docker image will just contain the build folder and nothing else - the project files were only used by to build the project in the builder layer, which then gets thrown away - it's just an intermmediary step.

Cool, now let's check that this works by building and running the Docker image.

First, let's stop the previously started container:

# See all running containers
docker ps

# Stop the previous container
# Copy "Name" or "Container ID" of your container
# and pass it into docker stop
docker stop <container name|id>

Next, let's rebuild the image and run it:

docker build . -t dockerized-react

# Notice we're now mapping port 80 inside the container 
# to port 3000 on the host machine!
docker run -p 3000:80 -d dockerized-react

Navigate to http://localhost:3000 to see it's still working!

That's it! Let me know in the comments below if this worked for you 💪

You can checkout the repository for this tutorial at: https://github.com/jsramblings/dockerize-react

What the project will look like when it's done

This guide will follow the conventions already established by create-react-app - e.g. build folder is called build, static assets are under public, etc.

At the end, this is the folder structure we'll have:

- public
   - index.html
- src
   - App.jsx
webpack.config.js
.babelrc
package.json

We'll go step by step and check that everything works after every stage:

1. Basic scaffolding: create project folder and serve plain HTML
2. Add Webpack and bundle a simple JS file
3. Add Babel for ES6 support
4. Add React

Without further ado, let's get started!

Step 1: Base scaffolding

First step is to create the project folder and add a plain HTML file.

To create the project and initialize the package.json, run these commands:

mkdir react-webpack
cd react-webpack
npm init -y

Then, add the main index html file - it usually sits in a public directory, so let's do that:

mkdir public
touch public/index.html

The index.html will just contain the base HTML5 boilerplate:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>React + Webpack</title>
</head>
<body>
    <h1>Hello React + Webpack!</h1>
</body>
</html>

Now let's check it runs so far by just serving the HTML we just created with npm serve.

npx serve public

And it does! If you navigate to http://localhost:3000, you should see the hello message we just added:

Step 2: Adding Webpack

For this section, it's best to just follow the latest official Webpack docs.

First, install Webpack:

npm install webpack webpack-cli --save-dev

Next, let's create a simple JavaScript file that we can configure Webpack to bundle:

mkdir src
touch src/index.js

We can just create a div with a hello message and add it to the document:

// index.js

const helloDiv = document.createElement("div");
helloDiv.innerHTML = "Hello from Javascript!";
document.body.append(helloDiv);

The, we need to configure Webpack by creating a webpack.config.js file in the root of the project:

// webpack.config.js

const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "build"),
  },
};

Finally, in package.json, add a new "build" script:

// ...
"scripts": {
    "build": "webpack"
},

Now, let's try it out! After running npm run build, you should see a new folder was created, called build, with a main.js file in it! 💪

Next, we need to move the static assets to the bundle.

More specifically, we want to also include the index.html file in the build folder.

Easiest way to do this is with the HtmlWebpackPlugin.

npm install html-webpack-plugin --save-dev

And update the webpack.config.jsfile:

const path = require("path");
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "build"),
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: path.join(__dirname, "public", "index.html"),
    }),
  ],
};

This will copy the file under public/index.html, copy it to the build folder and inject a link to the bundled JS file (main.js).

Let's try it out!

npm run build
npx serve build

And it works! You should now also see the message "Hello from Javascript" :D

Adding Webpack dev server

So far, it was ok to just use npx serve to check our app works, but in real life, it's easier to just use the webpack-dev-server, so let's add that as well.

npm install --save-dev webpack-dev-server

Then, configure it in the Webpack config:

{
  // ...,
  devServer: {
    static: {
      directory: path.join(__dirname, "build"),
    },
    port: 3000,
  }
}

... and then add npm run start script to package json; and while we're there, pass in the right "mode":

{
  // ...,
  "scripts": {
    "build": "webpack --mode production",
    "start": "webpack serve --mode development"
  }
}

Finally, check that it works: run npm run start,  open http://localhost:3000 and check the app still works as before.

Step 3: Adding Babel

This is useful for allowing us to use all ES6 features and having them transpiled down to JS versions that all browsers can understand. (If you want to learn more about what Babel preset-env is and why it's useful, this article by Jacob Lind is a great overview).

First, let's install the required packages:

npm i @babel/core @babel/preset-env babel-loader --save-dev

Next, update the Webpack config to tell it to pass the files through Babel when bundling:

{
 // ...,
 module: {
    // exclude node_modules
    rules: [
      {
        test: /\.(js)$/,
        exclude: /node_modules/,
        use: ["babel-loader"],
      },
    ],
  },
  // pass all js files through Babel
  resolve: {
    extensions: ["*", ".js"],
  }
}

Then, create the Babel config file - .babelrc. This is where we configure Babel to apply the preset-env transform.

// .babelrc

{
  "presets": [
    "@babel/preset-env"
  ]
}

Optionally, update the index.js to contain some ES6 features that wouldn't work without Babel 😀 (actually they do work in most browsers, but for example IE still doesn't support Array.fill).

// Use a feature that needs Babel to work in all browsers :)
// arrow functions + Array fill

const sayHelloManyTimes = (times) =>
  new Array(times).fill(1).map((_, i) => `Hello ${i + 1}`);

const helloDiv = document.createElement("div");
helloDiv.innerHTML = sayHelloManyTimes(10).join("<br/>");
document.body.append(helloDiv);

Finally, let's check everything works - run npm run start and check the app correctly runs:

Step 4: Add React

Finally, we can add React 😅

First, install it:

npm i react react-dom --save
npm i @babel/preset-react --save-dev

Then, update the .babelrc file to also apply the preset-react transform. This is needed, among other things, to support JSX.

// .babelrc

{
    "presets": [
      "@babel/preset-env",
      ["@babel/preset-react", {
      "runtime": "automatic"
    }]
    ]
}

Also, we need to update the Webpack config to pass jsx files through Babel as well:

// webpack.config.js

{
  // ...,
  module: {
    // exclude node_modules
    rules: [
      {
        test: /\.(js|jsx)$/,         // <-- added `|jsx` here
        exclude: /node_modules/,
        use: ["babel-loader"],
      },
    ],
  },
  // pass all js files through Babel
  resolve: {
    extensions: ["*", ".js", ".jsx"],    // <-- added `.jsx` here
  },
}

Next, let's create a React component, so we can check that everything works:

// src/Hello.jsx

const Hello = () => <h1>Hello from React!</h1>;

export default Hello;

And add it to the main app file:

// index.js

import React from "react";
import { createRoot } from "react-dom/client";
import Hello from "./Hello";

const container = document.getElementById("root");
const root = createRoot(container);
root.render(<Hello />);

Finally, we also update the index.html to provide a "root" node for the app:

<!-- index.html -->
<!-- ... -->
<body>
    <div id="root"></div>
</body>

Let's check that it works - run npm run start and you should see "Hello from React!":

Also, check there are no errors in the console.

You can also check that the app correctly runs in production, by running npm run build and then npx serve build.

That's it!

See the full code for this tutorial on Github: https://github.com/jsramblings/react-webpack-setup

This article aims to give a simple, straightforward overview of the steps needed to add JWT auth to a Node app.

We'll start from an unprotected API with a super secret resource and go towards securing it with JSON Web Tokens (JWTs).

What we'll build

Our API will only contain two endpoints:

• /login - will return the token
• /super-secret-resource - the information that only logged in users should access

Step 1: Creating a Node API with Express

Let's start from the barebones - just an API that returns a very important resource, that should only be accessed by logged in users. This endpoint should return 401 Unauthorized if the user is not logged in. Since we don't have the /login endpoint yet, it will just always return 401 for now.

Create a new folder for the project, run npm init -y to initialize the project and run npm install express to install express.

Next, create a server.js file for the node app. In its simplest form, this is how the API would look:

// server.js
const express = require("express");
const app = express();

app.get("/super-secure-resource", (req, res) => {
  return res
    .status(401)
    .json({ message: "You need to be logged in to access this resource" });
});

app.listen(3001, () => {
  console.log("API running on localhost:3001");
});

To start the API,  run node server.js in the console.

To check that the endpoint cannot be accessed, run curl:

curl -i localhost:3001/super-secure-resource

// Will output:
// 
// HTTP/1.1 401 Unauthorized
// X-Powered-By: Express
// Content-Type: application/json; charset=utf-8
// Content-Length: 62
// ETag: W/"3e-eJQzoUv1nk6AKpsmnnXBmFvKrI4"
// Date: Sat, 22 Jan 2022 09:05:53 GMT
// Connection: keep-alive
// Keep-Alive: timeout=5
// 
// {"message":"You need to be logged in to access this resource"}

The -i flag tells curl to also return the headers, so we can see the HTTP status code.

Notice the 401 HTTP status code - which stands for "Unauthorized" - and the message we returned from the endpoint.

Step 2: Return a JWT token on successful login

Next, we want to allow users to login and send back a verified token if their user and password are correct.

Since setting up a full database of users and password is out of the scope of this article, we'll just hardcode an admin/admin user and check for that as an example.

The first step is to install the npm jsonwebtoken module. This package will help us sign and verify JWT tokens.

npm install jsonwebtoken

Then, the endpoint will look like this:

const express = require("express");
const jsonwebtoken = require("jsonwebtoken");

// The secret should be an unguessable long string (you can use a password generator for this!)
const JWT_SECRET =
  "goK!pusp6ThEdURUtRenOwUhAsWUCLheBazl!uJLPlS8EbreWLdrupIwabRAsiBu";

const app = express();
app.use(express.json());

app.post("/login", (req, res) => {
  const { username, password } = req.body;
  console.log(`${username} is trying to login ..`);

  if (username === "admin" && password === "admin") {
    return res.json({
      token: jsonwebtoken.sign({ user: "admin" }, JWT_SECRET),
    });
  }

  return res
    .status(401)
    .json({ message: "The username and password your provided are invalid" });
});

Some things to note here:

• the JWT_SECRET should be an unguessable long string
• the part that actually does the signing is: jsonwebtoken.sign({ user: "admin" }, JWT_SECRET)

We can check a token is returned with curl:

curl -X POST http://localhost:3001/login --header "Content-Type: application/json" --data '{ "username": "admin", "password": "admin" }'

// {"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJpYXQiOjE2NDI4NDQ0NTR9.O_710gS-6t9nmqvW0_E1GlP7MdoLMFR85GXUUeskNi8"}

You can decode the token and see what it contains on jwt.io

Some things to note:

• The "Header" of the token contains the algorithm used - in our case, the algorithm for signing the token is HS256
• You can input your secret in the bottom right to have jwt.io verify the token signature (if the signature is verified, it means the token hasn't been tampered with)
• Besides the { user: admin } which we encoded, there's also another property there - iat, added by the jsonwebtoken library; this stands for "Issued at" - i.e. when the server created the token (as Unix timestamp)

Step 3: Send the token to the /super-secure-resource and verify it to allow access

Now let's use that token to allow the logged in user to access the restricted resource!

In order to do that, we will need to send the token to the API (as an Authorization header) and then verify the token on the server:

import jwt from "jsonwebtoken";

app.get("/super-secure-resource", (req, res) => {
  if (!req.headers.authorization) {
    return res.status(401).json({ error: "Not Authorized" });
  }

  // Bearer <token>>
  const authHeader = req.headers.authorization;
  const token = authHeader.split(" ")[1];

  try {
    // Verify the token is valid
    const { user } = jwt.verify(token, process.env.JWT_SECRET);
    return res.status(200).json({
      message: `Congrats ${user}! You can now accesss the super secret resource`,
    });
  } catch (error) {
    return res.status(401).json({ error: "Not Authorized" });
  }
});

When doing curl, the resource will now be accessible 💪:

curl -i localhost:3001/super-secure-resource --Header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJpYXQiOjE2NDI4NDYzMzV9.gQj-qjoQwtvyU2XzER6yiT-T4DwYphjMft-kogW978c'

// Will return:
//
// HTTP/1.1 200 OK
// X-Powered-By: Express
// Content-Type: application/json; charset=utf-8
// Content-Length: 69
// ETag: W/"45-9rvFFDk8vkfruRd3Ok0vQNGIdMk"
// Date: Sat, 22 Jan 2022 10:15:03 GMT
// Connection: keep-alive
// Keep-Alive: timeout=5
//
// {"message":"Congrats! You can now accesss the super secret resource"}

Why this works:

• By signing the token, you ensure that the server can check that whatever token it receives, was created by itself
• If you try to tamper with the token, you'll invalidate it! The server will tell it's been tampered, so it will not authorise you!
• Try it out: take the token, change it in jwt.io and try again -> it will fail!

Make it yours!

I specifically kept the source code for this article very barebones. Go ahead and improve it!

• Add nodemon to automatically reload the server when you change the API
• Add nodeenv and move the JWT_SECRET to as an environment variable
• Setup an actual database with users and passwords
• Add more endpoints and move the code that verifies the token in an express middleware

This can work fine at the beginning - but what if you want to answer bigger questions about your app - like whether using Context has an impact on the performance of your app? Or simply, what if you're tired of scrolling through tens of console.logs figuring out what executed when?

Then it's time to use the React DevTools! Not only do they allow you to visually see what components rerender, but you can also investigate what caused each rerender and easily spot what components are taking longest to render.

Using React DevTools to highlight what components rerendered

There's a checkbox well hidden in the React DevTools settings that allows you to visually highlight the components that rerendered.

To enable it, go to "Profiler" >> click the "Cog wheel" on the right side of the top bar >> "General" tab >> Check the "Highlight updates when components render." checkbox.

Then just interact with your app as usual and watch it all light up ✨

Using React DevTools to find out the cause of a rerender

Now that you can see your component rerendered, the next question is .. why?

There's a very handy tooltip that shows up when hovering over a component in the "Flamegraph", that shows the reason for a render under the "Why did this render?" heading.

To see this, you need to record a "Profiler" session.

For example, if you your component re-renders after you click a button, you can click record to start profiling, click the button in question, then stop profiling and see the details of what happened when the button was clicked.

Here's how to read the profiler output:

• In the top right you have the number of React commits - each bar represents a moment when the React component tree changed and a change was commited to the DOM
• The "Flamegraph" shows the component tree and what changed - "grey" means the component did not rerender

Hovering over each component will reveal why it rendered in the "Why did this render?" subheading.

Possible values you can expect to see as reasons for a component rerendering:

• "This is the first time the component rendered."
• "Context changed"
• "Hooks changed"
• "Props changed"
• "State changed"
• "The parent component rendered."

You'll notice that sometimes the reason is not very detailed - simply saying "hook changed" instead of the details of what hooked changed. This is expected and it happens because sometimes the DevTools simply does not have access to that information or because it would be too slow to retrieve.

When you click a component in the "Flamegraph", the right sidebar will update to show all renders of that component instance and why they happened:

Bonus tip: See at a glance what components took longest to render

It took me a while to figure this one out, but the colors in the "Flamegraph" actually have a meaning: "cool" colors - like shades of blue - signify the component took little time to render compared with everything else and "warm" colors - like orange and red - signify the component took a longer time to render 😀

Notice how I just said "more time" or "less time" to render - that's because what is slow or fast is relative to your specific app and total render time. So it could be that a "yellow" component rerendered very fast if it's part of a simple component tree, or for a "blue" component to actually take a very long time to render if the whole app is very slow.

Bonus tip: See what DOM changes actually happened

Even if a component rerendered, it doesn't mean that any changes were actually applied to the DOM - it could be that the output of render was the same as before, in which case React does nothing. But how can you check? How can you visually see what DOM parts were rerendered?

The Chrome DevTools have a very useful setting for this - "Paint flashing". This will highlight all elements of a page that were "repainted". To enable it, you need to click the "Settings" menu, then "More settings" and then "Rendering" and check the "Enable paint flashing" checkbox.

Try it out for yourself!

You can find the sample app used for this blog post at https://stackblitz.com/edit/react-3cmy6b. (Make sure to click "Open in New Window" in the top bar in order to see the app outside of the StackBlitz environment, which makes it easier to profile. )

Can you figure out why all "cards" render when just one is clicked? And moreover, can you fix it? 😀

Fork the code and share your solution in the comments below!

When there is complex business logic

Structuring your code with actions allows for better encapsulation of business logic.

Also, it allows you to separate the description of the action (WHAT happened) from how the state should update because of it (HOW it should be handled).

A simple example to showcase this is updating the state when the user navigates to the next page on a paginated list view.

With the hook, this could look like this:

setState(state => { ...state, page + 1})

However, with actions, you can add more semantics to this event and encapsulate the logic:

// action
dispatch({ type: 'GO_TO_NEXT_PAGE' })
// reducer
case 'GO_TO_NEXT_PAGE':
  return { ...state, page: state.page + 1}

In the future, if you decide something else needs to happen when the user clicks the "Next page" button, you only need to update one place: the reducer.

While this is a simple example, for deep nested values or arrays of objects, abstracting away the state update logic can be very valuable.

When there are many ways the state can be updated

In most situations, there are only a couple events that update the state - take for an example a simple login flow, where you only need to track loading, success and error states. In this case,  useReducer does not add that much value.

However, imagine a more complex login process, like multi-factor authentication, where the user needs to be guided over several screens - to enter his password, to enter the one time token - and you need to handle all sorts of edge cases like the QR code expiring, the password being incorrect etc.

In these situations reducers can really make it easier to follow the different component states and how they change.

When you need better debugging

Tracking how the component state changes after each setState  is generally harder to do than just having all changes go through a reducer.

Regardless if you prefer using console.log  or breakpoints, it's easier to add just one log/breakpoint in the reducer as opposed to one for each  call sprinkled across the component.

And if you ever decide to switch to Redux, the Redux DevTools make for a great debugging experience.

To wrap up, you don't need to jump to useReducer as soon as you have multiple useState hooks in your component. Many times, it's enough to just bundle all the state values in one object. However, if it becomes hard to figure out what's going on, useReducer can be a very helpful tool!

If you're interested to read more, I've found these articles helpful in my research:

• https://reactjs.org/docs/hooks-reference.html#usereducer
• https://reactjs.org/docs/hooks-faq.html#how-to-avoid-passing-callbacks-down
• https://overreacted.io/a-complete-guide-to-useeffect/#why-usereducer-is-the-cheat-mode-of-hooks
• https://kentcdodds.com/blog/should-i-usestate-or-usereducer
• https://www.robinwieruch.de/react-usereducer-vs-usestate

However, what if one of the members of the object you're updating is a reference?

Do you have to create a new version of that object/array as well?

const [order, setOrder] = useState({ 
  id: '12345',
  customer: 'John Doe',
  tags: ['black', 'day-trip'],	// <-- this is a reference!
  shippingAddress: {			// <-- this is also a reference
    street: 'Steiner St. 27',
    city: 'San Francisco'
  }
})

You don't need to deep clone when mutating state

If you only need to change one of the basic props of your object, it's ok to leave everything else the same - i.e. shallow copy the other properties that are nested.

const newOrder = { ...order, name: 'John Doe The Second'}

... unless the nested property actually changed

But what if something inside the nested reference changes? Then indeed, you would  need to deep clone that:

// Let's add a new tag
const newOrder = { 
  ...order, 
  tags: [
    ...order.tags, 
    'some-new-tag'
  ]
};

// .. or update the shipping address
const newOrder = { 
  ...order, 
  shippingAddress: { 
    ...order.shippingAddress, 
    city: 'New York'
}}

But why is it that you don't need to deep clone?

You've seen that it's enough to do shallow copies of nested properties if they haven't changed .. but why?

It all boils down to why you create copies in the first place - to let React know that your state changed so it can rerender. If you also create new references for nested props as well, React will assume those changed as well, and rerender them!

So if you had a component showing the list of tags or the shipping address, and you would deep copy those when updating the state, React would re-render them even if they hadn't changed, just because a new reference was passed!

Further reading

I hope you found this useful! If you want to learn more about how references work and immutably changing state, make sure to check out these links as well:

• https://daveceddia.com/javascript-references/
• https://redux.js.org/faq/performance#do-i-have-to-deep-clone-my-state-in-a-reducer-isnt-copying-my-state-going-to-be-slow

I am trying to make a login form in react with typescript. But setEmail method is not accepting value. It says Argument of type 'string' is not assignable to parameter of type 'SetStateAction'. What should I do to solve it?

If you've used React with Typescript before, you've probably seen it yourself as well.

So what's going on? What does the error message mean?

If I were to rewrite that error message and make it more verbose, it would sound something like "the value e.target.value (of type string) cannot be passed as an argument to the setEmail function - since its type is SetStateAction<undefined>, which means it expects an undefined value"

While rewriting the error message clarifies a bit what it refers to, it still makes no sense that it would expect an undefined value to be passed! Why is that?

Why does setEmail expect an undefined value?

It's because when defining the email state, no type was explicitly defined.

Theoretically, when using the useState hook with Typescript, you would need to explicitly specify the type of state you're defining:

const [email, setEmail] = useState<string>();

If you don't do this, Typescript will try to just guess what value you're expecting. That's why it will fill the blanks for you and "translate" useState() to useState<undefined>().

Does this mean you always need to pass in the type when calling useState?

Not necessarily. If you pass in an initial state value, Typescript might be able to correctly guess the type.

I said before that given useState(), Typescript will just assume you meant useState<undefined>().

However, if you passed an empty string as an initial value -  useState('') -, Typescript will be able to figure out you passed a string and will assume you mean useState<string>('').

This is called Typescript inference and it's quite powerful.

Fixing the error

So, to wrap up, in order to fix the error, you have two options:

1. Explicitly type the state when initially declaring it:

const [email, setEmail] = useState<string>();

2. Help Typescript infer the state type by passing in an initial value:

const [email, setEmail] = useState('');

That's it! I hope you found this useful. Let me know in the comments below if you still have any questions :)

const [data, setData] = useState(null);
const [isLoading, setLoading] = useState(false);

// on receiving the API response 
setIsLoading(false);
setData(data);

Depending on whether your code runs as part of an event handler or inside a regular function, this will trigger two rerenders or just one, based on whether React batches the setState calls or not.

Until React 18, we only batched updates during the React event handlers. Updates inside of promises, setTimeout, native event handlers, or any other event were not batched in React by default.
https://github.com/reactwg/react-18/discussions/21

This behaviour will change in React 18, but until then, what can you do to prevent multiple unnecessary rerenders and potentially invalid states?

Approach 1: Group related state variables in one state object

It's a good practice to analyse the things you keep in the state and see whether they change together or not.

In this case, the data and isLoading variables do change together - we always want the loading to stop when the data is received

Thus, it makes sense to create just one state for both:

const [response, setResponse] = useState({ data: null, isLoading: false  })

// on receiving the API response
setResponse({ ...response, data, isLoading: false })

While this works for very simple cases, in practice, it can become tedious and error prone, since you need to manually merge the previous state and the new changed values every time.

This is way a better approach is to switch to using the useReducer hook.

Approach 2: Refactor your code to use the useReducer hook

Let's see how the same example would look using useReducer:

const reducer = (state, action) => {
  switch(action.type) {
    case 'API_SUCCESS':
      return {
        ...state,
        data: action.payload.data,
        isLoading: false
      }
    default:
      return state;
  }
}

const initialState = { data: null, isLoading: false}
const [state, dispatch] = useReducer(reducer, initialState)

// on receiving the API response 
dispatch({ type: 'API_SUCCESS', payload: { data }})

While this does increase the complexity of the code a little, in the long term it might be a better choice:

• it makes it easy to extend the component with new functionality: for example, handling the error states can be added with a few lines changes in the reducer
• it makes the component state more predictable: all state transitions are defined in one single place, making it easier to reason about how the state changes
• it prevents invalid state values (e.g. isLoading being false, but the data not being updated yet) and unnecessary rerenders, as the state is only updated once no matter how many values changed

I hope you found this useful!

If you'd like to read more on the topic, make sure to take a look how batching will work in React 18.

import React, { useState, useEffect } from 'react'

const PokemonList = () => {
    const [pokemons, setPokemons] = useState([]);
    useEffect(async () => {
        const data = await fetch(`https://pokeapi.co/api/v2/pokemon?limit=10`).then(response => response.json());
        setPokemons(data.results);
        console.log('New pokemons list ', pokemons);
    }, [])
    
    return <ul>{pokemons.map(pokemon => <li key={pokemon.name}>{pokemon.name}</li>)}</ul>
}

The API returns correctly, you update your state by calling setState, yet when you log the value, it always comes back empty?

Well, maybe everything works fine just that you're logging at the wrong time 🙈

Why does this happen?

When logging inside  useEffect, you're using the state value that was captured in the closure at the beginning of the render. So that's why you're always seeing the empty array.

Your code is probably working just fine, and it's just the console.log looking at an outdated value!

How to fix this

Moving the console.log right before the return statement will instead look at the latest state value and log the updated list of pokemons 💥

Deep dive: Logging inside useEffect

Let's do a step by step walkthrough of what happens when the component is rendered. Notice I added a lot of extra console.log statements:

import React, { useState, useEffect } from 'react'

const PokemonList = () => {
    console.log('======= RENDER START =======')
    const [pokemons, setPokemons] = useState([]);
    useEffect(async () => {
        const data = await fetch(`https://pokeapi.co/api/v2/pokemon?limit=10`).then(response => response.json());
        console.log('API Returned:', data.results);

        setPokemons(data.results);
        console.log('State right after setPokemon: ', pokemons);
    }, [])
    
    console.log('State right before render: ', pokemons);
    return <ul>{pokemons.map(pokemon => <li key={pokemon.name}>{pokemon.name}</li>)}</ul>
}

Pause for a second - can you guess what the order of the console.logs is and what they will output?

...

...

Here's what the component will log:

======= RENDER START =======
State right before render:  []
API Returned: (10) [{…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}]
======= RENDER START =======
State right before render:  (10) [{…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}]
State right after setPokemon:  []

So what's going on?

RENDER 1

• state is []
• a new function is created to be passed into useEffect
• --> function creates a closer over the current value of state: []
• effect is called
• --> API is called to load the data
• --> data is successfully retrieved
• --> setState is called to update the pokemon list
• --> --> RENDER 2 starts
• --> console.log statement is called logging state value wrapped in closure - [] -> the old one!

RENDER 2

• state is now the list of pokemons
• a new function is created to be passed into useEffect
• --> function creates a closure over the current value of state: the full list of pokemons
• effect is on longer called, since it was defined with empty deps array`, which means it only gets run on the first render

So the console.log that outputs the empty array is actually a stale value, captured in the first render!

To make sure you really understand the flow, try drawing a diagram of the flow above with pen and paper!

I hope you found this helpful! Let me know in the comments below if you still have any questions 🙏

I was recently browsing a reddit thread about monorepos and sharing code between multiple apps and someone mentioned:

In my experience a monorepo with code symlinked at the src level is the best. The other options are a pain in the ass

And I wondered - what does "monorepo with code symlinked at the src level" even mean? And how would you go about setting up something like this?

A bit of browsing through the yarn docs and I stumbled on this piece:

yarn add link:/path/to/local/folder installs a symlink to a package that is on your local file system. This is useful to develop related packages in monorepo environments.

So then a monorepo setup using yarn symlinks would simply consist of several libraries and apps, stored as siblings in one main repository, which reference each other through yarn local dependencies.

This can be a great way to share code if:

• you're looking for a simple solution to share code
• you usually release your apps together (i.e. frontend + backend that share a library)

This might not be the best option if:

• you want to release and publish each package / app independently
• you want to be able to lock the shared package to a specific version, if needed

If you think this might be a good solution for you, read along for a step by step walkthrough of how to set this up.

Folder structure

For the sake of this example, we'll use two projects - project-a and project-b - and a library that I named very bluntly shared-code 😃

All the code is available on Gitlab, if you want to check it out yourself.

Our monorepo will simply have all of these as siblings at the root level:

- shared-code
  - package.json
  - yarn.lock
- project-a
  - package.json
  - yarn.lock
- project-b
  - package.json
  - yarn.lock

Notice how each app / library is completely independent and has its own package.json and yarn.lock file. This is good because it keeps each project simple and fully contained.

Adding dependencies

To make shared-code available in both project-a and project-b you can simply run yarn add link:/path for each:

cd project-a
yarn add link:../shared-code
cd ..
cd project-b
yarn add link:../shared-code

This will add shared-code as a dependency in the package.json file:

Local development flow

When something is changed in the shared-code library, does it get automatically refreshed or do you need to always rebuild the package?

The short answer is - it depends.

If you use Create React App, this won't work. First, the app expects the shared-code library to already be built, and second, the default CRA Webpack config does not detect changes in the shared-code, as it's outside of its src folder.

If you use your own custom setup, you can ensure hot reload by customizing your webpack config to detect changes in the symlinked packages. This is where having all the code under src might come in handy.

Continuous integration

How would this work in CI?

Since all the code is in the same repository, the library will always be available to yarn on yarn install. However, yarn assumes the shared-code is already built, so will need to manually do this step when building any of the projects:

# Sample CI build script
# 1. First build the `shared-code`
cd shared-code
yarn install
yarn build
cd ..
# 2. Build the project
yarn install # Will symlink `shared-code` to the current `node_modules`
yarn build

That's it!

Caveats

This might make for a simple way to setup code sharing and a seamless developer experience, but there are several downsides to be aware of.

The most important one is related to the fact that both project-a and project-b always use just one version of the shared-code - the latest one available at a given point in time.

Since the shared-code is not published to an npm repository it's not possible to lock in a certain version. This means that there's a high chance that a change needed for project-a might break project-b unexpectedly.

Where to go from here

While this setup is good to get started, with time you might "grow" out of it.

If you notice a lot of your dependencies are duplicated in each of the apps / packages, and you'd like to hoist them to the root level, you might want to look into using Yarn Workspaces.

If you decide you want to publish the packages to an npm repository and want better versioning and publishing support, you might want to look at Lerna.

I hope you found this useful! Let me know in the comments below if you have any questions or thoughts!

If you're looking for a simple way to deploy a CRA app everytime you push new changes, Gitlab Pages can be a great way to do this.

By the end of this article you'll learn how to:

• setup a GitLab CI pipeline to build the app on every new commit
• deploy the app to GitLab Pages on every commit to master, automatically

This walkthrough assumes you're using Gitlab to host your repository.

Step 1: Setup the CI pipeline to build the project

What we want is to run yarn build after every commit and to save the contents of the build folder as a GitLab artifact that we can later use.

If you haven't already, create a .gitlab-ci.yml file in the root of your project:

stages:
  - build

build:
  image: node:latest    # Run the job in a `node` docker image
  stage: build
  script:
    - yarn install      # Run `yarn install` and `yarn build`
    - yarn build
  artifacts:
    paths:
      - build/          # Save the build result as an artfact

After pushing your changes, you should already see the pipeline running under  the "CI / CD >> Pipelines" menu.

Step 2: Configure the React app to be served from a subfolder

By default, CRA apps expect the app will be served from the root of a server.

However, in GitLab Pages the app will be served from a subfolder (which represents the project name), and this will cause the React app to break and show the dreaded white page.

The fix is to customize the base path of the React app. There are two ways to configure this, depending on whether you use routing or not (or to be more specific: "if you are using the HTML5 pushState history API or using client-side routing").

If you don't use routes

The easiest way to set this up if you don't use routes is to set the homepage attribute in your package.json to the current folder - . (see official docs).

If you use routing

Then you will need to hardcode the full URL. I recommend configuring the URL by passing in an environment variable at build time, not to pollute your package.json with paths.

First, you will need to figure out the URL of your Gitlab Pages site.
You can find it in the sidebar menu, under "Settings >> Pages".

For example, for my example app, the project URL is https://gitlab.com/jsramblings/coffee-corner and the corresponding Gitlab Pages URL is https://jsramblings.gitlab.io/coffee-corner/.

To pass the URL as an environment variable, we can pass the extra variables key to the build job:

stages:
  - build

build:
  image: node:latest    
  stage: build
  variables: 
    # Replace this with your site URL
    PUBLIC_URL: https://jsramblings.gitlab.io/coffee-corner/  
  script:
    - yarn install      
    - yarn build
  artifacts:
    paths:
      - build/          

Step 3: Setup the GitLab Pages deploy

In order to have the site deployed automatically on every change to the code, we will add a new job to the CI pipeline.

Gitlab Pages expects two things from the deploy job:

• it must be named pages
• it must publish its artifacts under a folder named public

# Stages run sequentially, so we add a new `deploy` stage 
# after the `build` one
stages:
  - build
  - deploy

build:
  ... # Same as before
  
pages:
  image: alpine:latest
  stage: deploy
  variables:
    GIT_STRATEGY: none        # Do not clone git repo
  script:
    # Rename the CRA `build` folder to `public`
    - mv build public         
  artifacts:
    paths:
      - public

That's it! Pushing your changes should already start deployting the app.

You'll see the two jobs - build and pages- in the Pipeline view, plus an extra pages:deploy job that confirms the site was published.

I hope you found this walkthrough useful, let me know in the comments below if you have any questions 🙏

So how can you reduce this duplication? And should you?

In general, it's ok to have a bit of duplication, as it increases readability, but as the pipeline grows, that might not be so feasible anymore.

Let's take a look at 3 possible strategies using a simple example where we'll extract the echo 'prepare' command, so it's no longer duplicated in every job.

build:
  script:
    - echo 'prepare'
    - echo 'build'

test:
  script:
    - echo 'prepare'
    - echo 'test'

Use a default before_script

If your command is something you want to run before all jobs, all the time, then the easiest way is to simply extract the common code as a before_script key at the beginning of the file:

before_script:
  - echo 'prepare'

build:
  script:
    - echo 'build'

test:
  script:
    - echo 'test'

While this does not give you a lot of flexibility, it's a very quick and straightforward way to reuse commands.

Use YML anchors

Anchors are YML's way of reusing code - you can think of them a little bit like functions.

You can define a block of configuration somewhere and create a reference to it using &. Then, you can use it with *.

Let's see an example:

# Create an anchor called `&prepare_step`
.prepare_step: &prepare_step
  - echo 'prepare'

build:
  script:
   # Merge the anchor into the `script` using `<<*:`
    - <<:*prepare_step
    - echo 'build'

test:
  script:
   # Aaand reusing the command here again
    - <<:*prepare_step
    - echo 'test'

You'll notice prepare_step job starts with a dot - this is intentional to prevent Gitlab from running that job; by starting it with a dot, it will be ignored, thus behaving like a "template".

Anchors can be tricky to master, so if you want to learn more I found this article to be helpful, and of course, the official Gitlab docs on anchors.

Use extends

While anchors can be quick to get started with, they do have their downsides. The main one I've encountered is that you can't use anchors to reuse code across several files - they only work within the same file.

If you want to reuse code across several files, then you can use the extends keyword. This works similar to inheritance - you define a "template" job that other jobs can then extend.

Some things to keep in mind regarding extends:

• if the key is a hash it will get merged
• if the key is an array, it will get overridden

.prepare_step:
  before_script:
    - echo 'prepare'

build:
  extends:
    - .prepare_step
  script:
    - echo 'build'

test:
  extends:
    - .prepare_step
  script:
    - echo 'test'

Here are the Gitlab docs on extends keyword and some details on its merging strategy.

It's all great, until you realize there are all these loose ends you need to think about 🙈

• will the git commit authors be kept correctly after the import?
• can I migrate issues / pull requests ?
• can I just stop the existing CI pipeline or do other teams / projects depend on it?

These are some of the things I've had to think about while recently migrating the project I am working on to GitLab.

Here's what I learned.

I found there are 3 approaches to the migration.

#1. Migrate everything at once

This means you would:

• Start using the GitLab as hosted git repository instead of GitHub
• Use GitLab as CI for your project
• The previous GitHub project is closed

This is the most straightforward way to go and should be your first choice if possible 🚀.

#2. Migrate your CI pipeline first

This means you would:

• Keep using GitHub as your hosted git repo
• Use GitLab as CI for your GitHub repo

Why would you want to do this?

• If there are external dependencies on your GitHub repo - e.g. Jenkins pipelines owned by other teams that can't/won't update them immediately
• If you want to run both your "old" CI pipeline and the Gitlab one in parallel for a while, to make sure there are no regressions in how the artifacts are built
• If you want to allow users to get used gradually to the GitLab ecosystem (i.e. not disrupt day to day work by switching cold turkey)

This might sound a bit like overkill, but for a bigger organisation with multiple teams and a more complex release process, this could make sense.

Once the other teams have also switched to GitLab, you can make the full switch and no longer use GitHub at all.

#3. Migrate fully but keep GitHub as a read-only mirror

This means you would:

• Use GitLab as the hosted git repository
• Use GitLab as CI
• Keep the GitHub repo, but make it read-only

Why would you want to do this?

• If you have an open source project and you want to keep the visibility that GitHub brings
• If you want to migrate 100%, but still have external dependencies (as described in step #2) -> this option would bring the best of both worlds 💪

This is the option I wish I had thought of when I migrated my project 😀 I was too much "in the middle of it" that I only realised this could be an approach after I finished the migration with option #2.

What worked for you?

Did you go through a migration from GitHub to GitLab? How did you approach it?

Here are some things I learned while doing this:

• Steps for correctly importing the commit authors
• Steps to get GitHub changes synced to the GitLab repo in real-time