Decoding React Minified Errors: A concise guide to understanding and resolving hydration discrepancies in Next.js/React applications.

Working on a project with Next.js (or React) comes with a learning curve. Learning how to utilize server-side rendering (SSR) is part of it. While learning to utilize SSR, there will be times of frustration and unexpected challenges; understanding hydration errors is one of them. In this blog post, we will walk through the steps to decipher console errors in Next.js/React caused by hydration errors and discrepancies between server and client-side renders.

I asked myself the same question, why decrypt? I used this term to grab your attention because the error you see in the console might not clearly explain which part of your HTML (code) is causing the issue, and which line it's in within your codebase. You will see errors like:

So if we look at one of these errors, you will see the error message: Text content does not match server-rendered HTML. You can check the rest of the messages in React docs for decoding error messages (423, 418). Okay, now we are one step closer to debugging what's happening. 

When you start debugging this issue and looking at the errors, you will realize that it happens with the page content. Since we are looking for a mismatch between server and client-side renders, we should focus on what might have caused this. Where does the error occur? Is it only in one of the page types or in all pages? Which component might have caused this? Before diving into specifics, what I did was understand which page type was causing it for me.

Lucky for me that it didn't take long; my individual blog page was the reason behind this console error.

I use Prismic and SliceMachine for the content so potentially, this could have taken a long time for me to figure out. Slices are a dynamic way to build content, more on that in Prismic's documentation.

After finding out that this error was caused by something inside the blog page, I checked for the possible reasons;

One of the slices; the difference between how they are returned from CMS and how they are rendered

I went through them one by one and realized that it was because of my syntax highlighting component which uses react-syntax-highlighter package under the hood. This brings me to; lazy loading slice (component) that renders code blocks.

Next.js supports lazy loading with its next/dynamic. When applied, lazy loading will defer the loading of the components, therefore, reducing the initial load. Since I am using my syntax highlighted components as slices and they are not needed everywhere, this made perfect sense to me. 

To use next/dynamic with named imports, without server-side rendering, we can do as follows;

const DynamicHeader = dynamic(() => import('../components/header'), {
  ssr: false,
})

That's how we can use next/dynamic package. Next up is applying this with react-syntax-highlighter. Since we are working towards a lighter and more dynamic component, we can take advantage of syntax highlighter's async packages.

For optimal bundle size for rendering ASAP, there's a async version of prism light & light. This versions requires you to use a bundler that supports the dynamic import syntax, like webpack.

Following the suggestion in react-syntax-highlighter readme, our dynamic import will be:

const SyntaxHighlighter = dynamic(
  () =>
    import('react-syntax-highlighter').then((highlight) => highlight.PrismAsyncLight),
  { ssr: false }
);

And voilà! No more console errors. Blog pages work as expected and React Minified Errors are gone!

In this blog post, we tried to understand the reasons behind React Minified Errors; starting with the error messages and debugging our app to see the possible reasons. We also used next/dynamic to fix the mismatch between server and client side renders. 

For lazy loading, the Next.js team created a guide on how to use next/dynamic. As for the hydration error, there are some other common causes considered and explained in the Next.js documentation.

Decrypt React Minified Errors

Exploring React Testing Library: A practical guide to setting up and testing React components, focusing on user perspective over implementation details, and demonstrating the process with a simple button component.

We will use Jest as our testing framework. For different examples, please check React Testing Library documentation.

Testing is an essential part of the development process, and the React Testing Library (RTL) makes it easy to test your React components. In this post, we'll discuss the benefits of using RTL for testing, how to set up the testing environment, and how to create and test a simple button component.

There are several benefits to using the React Testing Library for testing your components:

RTL is designed to test the behavior of your components from the user's perspective, rather than the implementation details. This means that your tests will be less brittle and more resistant to changes in the implementation of your components.

RTL encourages the use of best practices such as testing the full rendering of your components and avoiding the testing of implementation details.

RTL provides a simple and intuitive API that makes it easy to write tests.

To get started with RTL, you'll need to install the library in your React project. You can do this by running the following command in your terminal:

npm install --save-dev @testing-library/react

Once the library is installed, you're ready to start writing tests!

Creating a Button Component and Writing Tests

Let's start by creating a simple button component:

export function Button({ onClick }) {
  return (
    <button
      onClick={onClick}
      type="button"
    >
      Click me
    </button>
  );
}

Next, we'll write a test for this component using RTL. First, we'll need to import the render and screen functions from RTL:

import { render, screen } from '@testing-library/react';

Depending on how we are testing the component, we need to import queries as well. More about queries can be found in documentation. Then, we'll write a test function that checks if the button component is rendered:

it("should render button component", () => {
  // Render the button component
  render(<Button onClick={onClick} />);

  // Find the button element using role query
  const button = screen.getByRole("button");

  // Check button is rendered
  expect(button).toBeInDocument();
});

For this example, we used getByRole query but we could achieve the same result with other queries (e.g. getByText) as well. And for the roles, RTL is compatible with HTML roles which can be found in W3C documentation. Next up, let's test the component when user clicks on the button:

it("should call onClick when the button is clicked", () => {
  // Mock onClick event
  const onClick = jest.fn();

  // Render the button component
  render(<Button onClick={onClick} />);

  // Find the button element using role query
  const button = screen.getByRole("button");

  // Fire click event
  fireEvent.click(button);

  // Check onClick is called when button is clicked
  expect(onClick).toBeCalled();
  expect(onClick).toBeCalledTimes(1);
});

This test actually checks the implementation detail (e.g. testing if the onClick event is called). What would be more beneficial for us in the long term is to test the component according to how user interacts with it. For our button component, we can bind the click to an event (interacting with another element maybe) and test that click makes the interaction work. To demonstrate, I will open open/close a modal when button is clicked and test that this behaviour is working as expected. First, let's refactor our code to add Button inside a component with the desired behaviour;

export default function App() {
  const [isOpen, setIsOpen] = React.useState(false);
  const handleClick = () => setIsOpen(!isOpen);

  return (
    <>
      {isOpen ? <div>Modal</div> : null}
      <Button onClick={handleClick} />
    </>
  );
}

Then, let's test App to see if clicking on Button opens the modal;

import { fireEvent, render, screen } from "@testing-library/react";

import App from "../src/App";

describe("App", () => {
  it("should render modal when button is clicked", () => {
    // Render the App component
    render(<App />);

    // Find the button element using role query
    const button = screen.getByRole("button");

    // Fire click event
    fireEvent.click(button);

    // Find modal using text query
    const modal = screen.queryByText("Modal");

    // Check modal is rendered
    expect(modal).toBeInDocument();
  });
});

After running the test above, you will see that the tests are passing, congratulations! 🥳

In this post, we've covered the basics of testing a React component with the React Testing Library. We've discussed the benefits of using RTL for testing, how to set up the testing environment, and how to create and test a simple button component. We've also looked at how to test the component without testing implementation details. 

Kent C. Dodds wrote a blog post about implementation detail free testing with more details, you can find the post below.

Testing React components with React Testing Library

Blog posts about my technical and life experinces and about new things I learn

Blogs