DEV Community: Jessie W.

Fix Next.js 14 hydration error with Zustand state management

Jessie W. — Tue, 19 Mar 2024 09:04:49 +0000

This post was originally published in my Medium blog.

With the release of Next.js 14, developers now have access to a range of powerful and experimental features. However, as we venture into these new functions, unique challenges arise such as hydration errors. This kind of error typically occurs when there’s a discrepancy in the rendered output due to how state is passed between the client and server.

🔖 TL;DR: You can find my example repo with the finished code here 😊

In this article, I’ll explain how persistent state works in Zustand with the Next.js App Router and implement a solution for resolving hydration errors.

Zustand: an alternative state management solution for React

Zustand simplifies state management for React applications. It’s light-weight and high performance, making it a popular choice among developers. Implementing is straightforward. Here’s a quick example to illustrate how it works. Firstly, install create next app with zustand:

npx create-next-app@latest
npm install zustand

Zustand share state between components using the persist middleware. This feature is particularly useful when working with local storage on the client side. A typical use case looks like this:

// store.ts
import { create } from "zustand";
import { persist } from "zustand/middleware";

interface BearState {
  bears: number;
  increaseBears: () => void;
  decreaseBears: () => void;
  removeAllBears: () => void;
}

export const useBearStore = create<BearState>()(
  persist(
    (set) => ({
      bears: 0,
      increaseBears: () => set((state) => ({ bears: state.bears + 1 })),
      decreaseBears: () => set((state) => ({ bears: state.bears - 1 })),
      removeAllBears: () => set({ bears: 0 }),
    }),
    {
      name: "bear-store", // default to LocalStorage
    }
  )
);

LocalStorage only available on the client side. When Next.js renders, it renders twice, first on then server and then client side. If we directly reference data in LocalStorage in our components, Next.js may detect that the content of our component when rendered is not the same during both renders, giving us a Hydration Error.

The Hydration Error in Next.js

This error typically arises when information used for component state is not passed between the client and the server, leading to a discrepancy in the rendered output. Next.js will tell you:

This example shows how we can use the bear-store from local storage above in our components to demonstrate this problem.

// hydration.tsx
"use client"; // (a)

import * as React from "react";
import { useBearStore } from "@/contexts/store";

const Hydration = () => {
  React.useEffect(() => {
    useBearStore.persist.rehydrate();
  }, []); // (b)

  return null;
};

export default Hydration;

// layout.tsx
import type { Metadata } from "next";
import Hydration from "@/contexts/hydration"; // (c)

export const metadata: Metadata = {
  title: "Next Zustand Demo",
  description: "Generated by create next app",
};

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html>
      <body>
        <Hydration />
        <main>{children}</main>
      </body>
    </html>
  );
}

a) Create client side component called hydration.tsx
b) Call persist state inside useEffect hook — this is to make sure it runs on client side
c) Import it into root layout.

When the code is run on server side, useBearStore.bears will always be 0, as we are managing our state in LocalStorage. When you first load the page, this won’t be a problem, as it will be initialised the same way on the client side. However, it can be resolved quite simply as follows:

// useState, useEffect hook
const [hydrated, setHydrated] = useState<boolean>(false);
useEffect(() => {
  setHydrated(true);
}, []);

// Render when it's hydrated
{isHydrated ? bears : "Loading..."}

On the initial hydration, we set a boolean variable named hydrated to false, indicating that hydration has not yet completed. On the initial render, both client and server side, the application will therefore render the text “Loading…” as the isHydrated check returns false. As the text is the same regardless of where it is rendered, we won’t see a Hydration Error.

Once hydration is completed, useEffect() sets the boolean to true, causing the component to re-render. This time as hydrated is now true, we can render the correct value of bears safely, showing the expected number to our user.

Demo

I have a working demo of this code available at https://next-zustand-starter.vercel.app/

When you land on the initial page, you will see the following and be able to click the buttons to control the bear-store kept in LocalStorage. As you click, the number of bears in the forest will change in realtime.

When you click the “another page” link, you will be taken to another page with a new component. This renders initially without the correct number of bears, but once hydrated on the browser will re-render, having retrieved the correct value from LocalStorage. You should be able to switch between the two pages seamlessly, with the data remaining in sync.

That’s it

Happy Coding!

Resources

Github: https://github.com/koalamango/next-zustand
Online demo: https://next-zustand-starter.vercel.app/
Nextjs: https://nextjs.org/docs/messages/react-hydration-error
Zustand: https://github.com/pmndrs/zustand

Cypress unit testing React components with TypeScript

Jessie W. — Sun, 02 Aug 2020 14:32:35 +0000

This post was originally published in my Medium blog.

At work, we've recently been shifting our testing strategy to use Cypress. We've found it's a powerful tool that has enabled fast and reliable end-to-end and integration tests, but there's one piece that until recently was missing: unit tests. Cypress introduced some experimental features designed to help with unit testing and over the last few days I’ve spent some time familiarising myself with these to see if we can do all our testing in one framework.

🔖 TL;DR: You can find my example repo with the finished code here 😊

Prerequisites

In this tutorial, I'm unit testing a Progress Bar component. It's built with React in TypeScript and styling with styled-components so we need all these dependencies.

Getting Started

To add and setup all these packages in package.json:

Cypress

$ yarn add -D cypress cypress-react-unit-test

Enable experimentalComponentTesting (don't worry, it's quite stable now) and assign componentFolder to your preferred location for your tests. I also added a condition to only target .spec files but that's optional.

{  
  "experimentalComponentTesting": true,
  "componentFolder": "cypress/component",
  "testFiles": "**/*.spec.*"
}

We also need to setup Cypress to include the unit test plugin. Add the following to cypress/support/index.js

import 'cypress-react-unit-test/support';

TypeScript

💡 You can skip this step if you are using create-react-app with TypeScript template because it doesn't require extra settings.

Cypress supports TypeScript as long as you have a tsconfig.json file. However, imports don't work unless you preprocess your TypeScript files.

Let's add the necessary packages to our dev dependencies if they're not already configured.

$ yarn add -D webpack ts-loader @cypress/webpack-preprocessor

In webpack.config.js: ts-loader is needed to preprocess TypeScript files.

{  
 rules: [
   {
    test: /\.tsx?$/,
    exclude: [/node_modules/],
    use: [
     {
      loader: "ts-loader",
      options: {
       transpileOnly: true,
      },
     },
    ],
   },
 ],
}

Add the webpack preprocessor to ./cypress/plugin/index.js

const preprocessor = require('@cypress/webpack-preprocessor');
module.exports = (on, config) => {
 const webpack = require('./webpack.config.js');
 on("file:preprocessor", preprocessor({ webpack }));
 return config;
};

Then make sure TypeScript understands Cypress' types by
adding this to tsconfig.json

{
  "compilerOptions": {
    "types": ["cypress"]
  }
}

And that's all the setup done, we are good to go!

Unit Testing Our First Component

I picked a Progress Bar component to unit test. You can view the Progress Bar Component on a Live Site and check how the functionality works in my Github repository.

What do we want to test?

A progress bar should be visible
A progress bar should setup its state correctly based on passed data
A progress bar should render correctly in different states

With unit tests, we're aiming to test functionality rather than styling itself. If you want to test all your styles then adding Snapshot or Visual Regression to your integration tests would be more suitable. In this example, we are testing state of the component - when the step changes, does the rendering change as we expect? This is also part of the functionality.

Add test scripts

./cypress/component/ProgressBar.spec.tsx

/// <reference types="cypress" />
import React from "react";
import { mount } from "cypress-react-unit-test";
import ProgressBar from "../../src/ProgressBar";
import GlobalStyle from "../../src/globalStyle";
describe("Progress Bar", () => {
 const mockSteps = ["Step 1", "Step 2", "Step 3", "Step 4"];
 it("renders steps", () => {
  mount(
   <ProgressBar steps={mockSteps}><GlobalStyle /></ProgressBar>
  );
  cy.get("ul li").first().should("have.text", "Step 1")
  .next().should("have.text", "Step 2")
  .next().should("have.text", "Step 3")
  .next().should("have.text", "Step 4");
  cy.get("ul li").find("span")
  .and("have.css", "background-color", "rgb(255, 255, 255)")
  .and("have.css", "border-color", "rgb(0, 182, 237)");
 });
 it("renders active steps", () => {
  mount(
   <ProgressBar steps={mockSteps} current={3}>
    <GlobalStyle />
   </ProgressBar>
  );
  cy.get("ul li:nth-child(2)").find("span")
  .and("have.css", "background-color", "rgb(0, 182, 237)")
  .and("have.css", "border-color", "rgb(0, 0, 0)");
  cy.get("ul li:nth-child(3)").find("span")
  .and("have.css", "background-color", "rgb(255, 255, 255)")
  .and("have.css", "border-color", "rgb(0, 182, 237)");
  cy.get("ul li:nth-child(4)").find("span")
  .and("have.css", "border", "3px solid rgb(198, 198, 198)");
 });
});

There are two key concepts here:

mount tells Cypress that we want it to render our React Component on its own rather than in the context of a whole application
mockData is used so we can test the Component outside the context of our application.

Our first test "renders steps" simply checks that the component has correctly setup the mockData that we passed to it. We can do this by checking that the text for each step matches what we passed in.

In our second test "renders active steps" we also set the third step to be "active" . We then expect that the component will render this with a blue open circle. We also expect the first and second step to be "completed" (with a blue background colour and white tick) and the fourth step should be "inactive" (a grey open circle). It's a simple test but very effective, we covered both functionality and state of the component.

Note that we only tested the styles that are changed by the component on state change, not all the styling.

Run yarn cypress open, you should see your browser load, the tests run and pass! 🎉

But some of my styles are missing?

Cypress is running unit tests against our component in isolation. When using styled-components, the style is self contained, we don't need to load external css or separate stylesheet. However, in some cases, we will rely on global styling (i.e: fonts, font size, spacing..etc) from the top level to ensure our component displays correctly during test.

The simplest solution is to also mount GloablStyle - we use this helper function to generate a special StyledComponent that handles global styles by styled-components.

import GlobalStyle from "../../src/globalStyle";
...
 mount(
  <ProgressBar steps={mockSteps}><GlobalStyle /></ProgressBar>
 );

While this is useful for us visually when we run the tests in our browser, it is not necessary; remember, we're only testing the functionality that is built into the component, not all of our styles!

Run Cypress unit testing with NPM scripts

I encountered an odd issue with NPM script. When adding cypress run into the script, it triggered all our tests including integrations. This is not ideal, we need to able to run unit tests on a specific component file or folder so we don't have to wait for everything to complete.

A useful tip I discovered is to add a separate command with yarn into our build script. Also for some reason two extra dashes are needed before -- spec to target file or folder.

"scripts": {
   "test:unit": "yarn cypress run -- --spec 'cypress/component/*.spec.tsx'"
}

That's it!

This is a quick walkthrough to explain how Cypress can unit test a React component. Setting up Typescript can be a little fiddly, but once you've got that done the testing is really straight forward. If you want to see more of what you can do with Cypress unit tests, this is a really repo with lots of examples to start diving in further https://github.com/bahmutov/cypress-react-unit-test

Hopefully this tutorial helps! 😃

Server side rendering Styled-Components with NextJS

Jessie W. — Wed, 10 Jun 2020 15:31:49 +0000

This post was originally published in my Medium blog.

I switched to styled-components for most of my projects nearly a year now but never used it with Next.js until recently. This might be a bit late to the party but I feel it's definitely worth sharing the neat trick of ServerStyleSheets.

🔖 TL;DR: You can find my example repo here 😊

How does it work?

Styled-Components

Styled-components supports concurrent SSR (server side rendering) with stylesheet rehydration. The basic idea is that when your app renders on the server, you can create a ServerStyleSheet and add a provider to your React tree which accepts styles via a context API. This doesn't interfere with global styles, such as keyframes or createGlobalStyle and allows you to use styled-components with React DOM's various SSR APIs.

NextJS

In Next.js, <Document /> wraps the <html>, <body>, <head> tags and runs them through a renderPage method which synchronously renders on the server side. We can override the default by adding a _document.js file in pages folder to inject the server side rendered styles into the <head>.

That's pretty neat, huh!

Getting Started

Make sure you have these packages in package.json:

{
"dependencies": {
  "next": "latest",
  "react": "^16.8.0",
  "react-dom": "^16.8.0",
  "styled-components": "latest"
},
"devDependencies": {
  "babel-plugin-styled-components": "latest",
}

And in .babelrc

{
  "presets": ["next/babel"],
  "plugins": [["styled-components", { "ssr": true }]]
}

Now, feel free to add your styles to ./pages/index.js. For example, let's add simple GlobalStyle for the heading and Styled.div for the container:

import Head from 'next/head';
import styled, { createGlobalStyle } from 'styled-components';
const GlobalStyle = createGlobalStyle`
 h1 {
   font-size: 4rem;
 }
`;
const Container = styled.div`
  text-align: center;
`;
export default function Home() {
  return (
    <>
      <Head>
        <title>SSR styled-components with Next.js Starter</title>
      </Head>
      <Container>
        <GlobalStyle />
        <h1>Hello, world!</h1>
      </Container>
    </>
  );
}

Finally, let's take a look at _document.js: this is where the magic happens.

Styled-components creates an instance of ServerStyleSheet This stylesheet retrieves any styles found in all the components inside our <App />. This then gets passed into our Html template later on.

import Document from 'next/document';
import { ServerStyleSheet } from 'styled-components';

export default class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const sheet = new ServerStyleSheet();
    const originalRenderPage = ctx.renderPage;

    try {
      ctx.renderPage = () =>
        originalRenderPage({
          enhanceApp: (App) => (props) =>
            sheet.collectStyles(<App {...props} />),
        });

      const initialProps = await Document.getInitialProps(ctx);
      return {
        ...initialProps,
        styles: (
          <>
            {initialProps.styles}
            {sheet.getStyleElement()}
          </>
        ),
      };
    } finally {
      sheet.seal();
    }
  }
}

sheets.collectStyles collects all of the styles from the app's components.
sheets.getElement() generates the style tag and you need to return it as props called styles.

Testing the app

To view it locally, run npm run dev then visit http://localhost:3000

If you disable JavaScript on the browser (e.g in Chrome: Settings / Site settings / JavaScript / Blocked), you should still be able to see the styling applied to headings and container, even though the JavaScript didn't run locally (see the screenshot below).

That's it!

This is a quick walkthrough to explain how to render server-side styled-components works with Next.js. The steps are pretty straight forward and easy to build on once you have the basics in place.

I remember in the past pulling my hair out to get styles working the way I wanted on the server side. Next.js and the support of styled-components are proving a really powerful tool to make this much simpler to achieve.

Hopefully this tutorial helps to ease some headaches for you! 😃

Focus on writing code not formatting: Prettier + ESLint

Jessie W. — Sat, 06 Jun 2020 23:01:54 +0000

This post was originally published in my Medium blog.

Stop wasting time formatting JavaScript, let your tools handle it automatically.

I confess that I used to be the type of coder who cared about coding standards, maybe a little bit too much. I once debated about semi colons like they’re such a big deal. Thinking back, I feel silly.

The thing is, it doesn’t really matter as long as your team are agreed on common rules, enforcing the same rules and style guides to your code. Preferably this should be automatic so you have less headaches with formatting and more time for actual coding!

Powerful Duo

We’ll use two popular tools to check and format our source code.

ESLint - is the most popular JavaScript linter which analyses code for common errors, including both non-standard formatting and possible bugs.
Prettier - is an opinionated code formatter. It supports many languages and integrates with most code editors. You can setup your own rules or just use the default setting without extra configuration.

Both tools come with an auto-fixing feature to fix the formatting of your code.

In this case, we’re going to use Prettier for this feature (eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style ... etc).

This means we’ll only use ESLint’s code quality features. These are the ones which enforce coding (best) practices and aim to reduce bugs and incorrect code (eg: no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors ... etc).

Getting Started

Install Prettier and extensions:

yarn add prettier prettier-eslint prettier-eslint-cli -D

Install eslint-config-prettier (disables formatting for ESLint) and eslint-plugin-prettier (allow ESLint to run Prettier):

yarn add eslint-config-prettier eslint-plugin-prettier -D

Then in .eslintrc.json add the following “extends” array to your configuration, making sure to put it last in the extends array. This makes sure it overrides all other config.

{
  "extends": ["prettier"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": ["error"]
  },
}

If you want to setup your own formatting rules, create a .prettierrc file in the root directory of your project. For example:

{
  "printWidth": 80,
  "singleQuote": true,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "jsxBracketSameLine": false,
  "parser": "babel",
  "semi": true
}

That’s it. You are ready to use Prettier and ESLint in your project.

Prettier Bonus Features

Using within code editors — most code editors have support for Prettier built in. You can make it run every time you save. For example: in WebStorm, press Alt+Shift+Cmd+P to easily format the code on the fly.
Running as a pre-commit hook — simply add config to package.json:

{
  "husky": {
    "hooks": {
      "pre-commit": "npm run prettier"
    }
  }
}

Conclusion

Prettier and ESLint can be adjusted to suit your needs.

They are useful tools to enforce consistent coding standards and styles within a team. They don’t just ease the effort of maintaining the code but also reduce on-boarding processes for any newcomers. Most importantly, they definitely mean less unnecessary meetings to discuss code-formatting and code review comments! More time saved to focus on actual coding.

If you haven’t tried it already, I’d strongly recommend you give it a go!

Enjoy 😃