ReactJS

How to test React custom hooks and components with Vitest

Published Mar 15, 2024

Updated Mar 15, 2024

5 min read

Introduction

In this guide, we'll navigate through the process of testing React hooks and components using Vitest—a powerful JavaScript unit testing framework. Discover how Vitest simplifies testing setups, providing an optimal solution for both Vite-powered projects and beyond.

Vitest is a javascript unit testing framework that aims to position itself as the Test Runner of choice for Vite projects and as a solid alternative even for projects not using Vite. Vitest was built primarily for Vite-powered projects, to help reduce the complexity of setting up testing with other testing frameworks like Jest. Vitest uses the same configuration of your App (through vite.config.js), sharing a common transformation pipeline during dev, build, and test time.

Prerequisites

This article assumes a solid understanding of React and frontend unit testing. Familiarity with tools like React Testing Library and JSDOM will enhance your grasp of the testing process with Vitest.

Installation and configuration

Let’s see how we can use Vitest for testing React custom hooks and components. But first, we will need to create a new project with Vite! If you already have an existing project, you can skip this step.

npm create-vite@latest

Follow the prompts to create a new React project successfully. For testing, we need the following dependencies installed:

Vitest as the unit testing framework JSDOM as the DOM environment for running our tests React Testing Library as the React testing utilities.

To do so, we run the following command:

npm install -D vitest jsdom @testing-library/react

Once we have those packages installed, we need to configure the vite.config.js file to run tests. By default, some of the extra configs we need to set up Vitest are not available in the Vite config types, so we will need the vite.config.ts file to reference Vitest types by adding /// reference types=”vitest” /> at the top of the file.

Add the following code to the vite.config.ts

/// reference types=”vitest” />

export default defineConfig({
  plugins: [react()],
  test: {
    globals: true,
    environment: 'jsdom',
    root: 'src/',
  }
})

We set globals to true because, by default, Vitest does not provide global APIs for explicitness. So with this set to true, we can use keywords like describe, test and it without needing to import them. To get TypeScript working with the global APIs, add vitest/globals to the types field in your tsconfig.json.

// tsconfig.json
{
  "compilerOptions": {
    "types": ["vitest/globals"]
  }
}

The environment property tells Vitest which environment to run the test. We are using jsdom as the environment. The root property tells Vitest the root folder from where it should start looking for test files.

We should add a script for running the test in package.json

"scripts": {
    "test": "vitest"
}

With all that configured, we can now start writing unit tests for customs hooks and React components.

Writing test for custom hooks

Let’s write a test for a simple useCounter hook that takes an initial value and returns the value, an increment function and a decrement function.

// useCounter.ts
export const useCounter = (initialValue: number) => {
  const [value, setValue] = useState(initialValue);

  const increment = () => {
    setValue((prev) => prev + 1);
  };

  const decrement = () => {
    setValue((prev) => {
      if (prev === 0) return prev;
      return prev - 1;
    });
  };

  return { value, increment, decrement };
};

We can write a test to check the default return values of the hook for value as below:

import { renderHook } from '@testing-library/react';
import { useCounter } from '../hooks/useCounter';
import { expect } from 'vitest';

describe('useCounter', () => {
  it('should return a default value', () => {
    const initialValue = 0;
    const { result } = renderHook(() => useCounter(initialValue));

    expect(result.current.value).toBe(initialValue);
  });
});

To test if the hook works when we increment the value, we can use the act() method from @testing-library/react to simulate the increment function, as shown in the below test case:

describe('useCounter', () => {
  //…
  it('should increment the initial value once', () => {
    const initialValue = 1;
    const { result } = renderHook(() => useCounter(initialValue));

    expect(result.current.value).toBe(initialValue);

    act(() => result.current.increment());

    expect(result.current.value).toEqual(2);
  });
});

Kindly Note that you can't destructure the reactive properties of the result.current instance, or they will lose their reactivity.

Testing hooks with asynchronous logic

Now let’s test a more complex logic that contains asynchronous logic. Let’s write a useProducts hook that fetches data from an external api and return that value

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

export const useProducts = () => {
  const [isLoading, setIsLoading] = useState(false);
  const [products, setProducts] = useState([]);

  const fetchProducts = useCallback(async () => {
    try {
      setIsLoading(true);
      const response = await fetch('https://fakestoreapi.com/products');

      if (!response.ok) {
        throw new Error('Failed to fetch products);
      }

      const data = await response.json();
      setProducts(data);
      setIsLoading(false);
    } catch (err) {
        setIsLoading(false);
    }
  }, []);

  useEffect(() => {
    fetchProducts();
  }, []);

  return { isLoading, products };
};

Now, let’s see what the test looks like:

import { renderHook, waitFor } from '@testing-library/react';
import { useProducts } from '../hooks/useProducts';

describe('useProducts', () => {
  //Spy on the global fetch function
  const fetchSpy = vi.spyOn(window, 'fetch');

  //Run before all the tests
  beforeAll(() => {
    //Mock the return value of the global fetch function
    const mockResolveValue = {
      ok: true,
      json: () =>
        new Promise((resolve) =>
          resolve([
            {
              id: 1,
              title: 'T-shirt',
              price: 109.95,
              Description: 'A nice t-shirt',
            },
          ])
        ),
    };
    fetchSpy.mockReturnValue(mockResolveValue as any);
  });

  //Run after all the tests
  afterAll(() => {
    fetchSpy.mockRestore();
  });

  it('should fetch products', async () => {
    const { result } = renderHook(() => useProducts());

    expect(result.current.isLoading).toEqual(true);
    await waitFor(() => expect(result.current.products.length).toEqual(1));
    expect(result.current.isLoading).toEqual(false);
  });
});

In the above example, we had to spy on the global fetch API, so that we can mock its return value. We wrapped that inside a beforeAll so that this runs before any test in this file. Then we added an afterAll method and called the mockRestore() to run after all test cases have been completed and return all mock implementations to their original function. We can also use the mockClear() method to clear all the mock's information, such as the number of calls and the mock's results. This method is handy when mocking the same function with different return values for different tests. We usually use mockClear() in beforeEach() or afterEach() methods to ensure our test is isolated completely. Then in our test case, we used a waitFor(), to wait for the return value to be resolved.

Writing test for components

Like Jest, Vitest provides assertion methods (matchers) to use with the expect methods for asserting values, but to test DOM elements easily, we will need to make use of custom matchers such as toBeInTheDocument() or toHaveTextContent(). Luckily the Vitest API is mostly compatible with the Jest API, making it possible to reuse many tools originally built for Jest. For such methods, we can install the @testing-library/jest-dom package and extend the expect method from Vitest to include the assertion methods in matchers from this package.

npm install -D @testing-library/jest-dom

After installing the jest-dom testing library package, create a file named vitest-setup.ts on the root of the project and import the following into the project to extend js-dom custom matchers:

import '@testing-library/jest-dom/vitest'

Since we are using typescript, we also need to include our setup file in our tsconfig.json:

// In tsconfig.json
  "include": [
    ...
    "./jest-setup.ts"
  ],

In vite.config.ts, we need to add the vitest-setup.ts file to the test.setupFiles field:

//vite.config.ts
    test: {
        //... 
        setupFiles: ['./vitest-setup.ts'],
    },

Now let’s test the Products.tsx component:

import { useProducts } from '../hooks/useProducts';

export const Products = () => {
  const { products } = useProducts();

  return (
    <div>
      <ul data-testid="product-list">
        {products.map((item) => (
          <li key={item.id} style={{ listStyle: 'none' }}>
            <div>
              <img src={item.image} width={80} height={120} />
              <h3>{item.title}</h3>
              <p>{item.description}</p>
            </div>
          </li>
        ))}
      </ul>
    </div>
  );
};

We start by spying and mocking the useProducts hook with vi.spyOn() method from Vitest:

import * as useProductsHooks from '../hooks/useProducts;

describe(“Products”, () => {
    const useProductsSpy = vi.spyOn(useProductsHooks, 'useProducts');
const items = [
        {
          id: 1,
          title: 'Fjallraven',
          description:
            'this is a test description',
          image: 'test.link.com',
        },
      ]
useProductsSpy.mockReturnValue({
        isLoading: false,
        products: items,
    });
});

Now, we render the Products component using the render method from @testing-library/react and assert that the component renders the list of products as expected and also the product has the title as follows:

describe(‘Products’, () => {
    /**... */
    it('should render the list of products and also find the title of the product', () => {
        //... 
     const { getByTestId, getByText } = render(
      <Products />
    );

    expect(getByTestId('product-list').children.length).toBe(1);
    expect(getByText('Fjallraven')).toBeInTheDocument();
    });
});

In the above code, we use the render method from @testing-library/react to render the component and this returns some useful methods we can use to extract information from the component like getByTestId and getByText. The getByTestId method will retrieve the element whose data-testid attribute value equals product-list, and we can then assert its children to equal the length of our mocked items array.

Using data-testid attribute values is a good practice for identifying a DOM element for testing purposes and avoiding affecting the component's implementation in production and tests. We also used the getByText method to find a text in the rendered component. We were able to call the toBeInTheDocument() because we extended the matchers to work with Vitest earlier. Here is what the full test looks like:

import { render } from '@testing-library/react';
import { expect } from 'vitest';
import { Products } from '../components/Products';
import * as useProductsHook  from '../hooks/useProducts';

describe('products', () => {
    const items = [
        {
          id: 1,
          title: 'Fjallraven',
          description:
            'this is a test description',
          image: 'test.link.com',
        },
      ]
    const useProductsSpy = vi.spyOn(useProductsHook, 'useProducts');
  it('should render the list of products and also find the title of the product', () => {
    useProductsSpy.mockReturnValue({
        isLoading: false,
        products: items,
    });
    const { getByTestId, getByText } = render(
      <Products />
    );

    expect(getByTestId('product-list').children.length).toBe(1);
    expect(getByText('Fjallraven')).toBeInTheDocument();
  });
});

Conclusion

In this article, we delved into the world of testing React hooks and components using Vitest, a versatile JavaScript unit testing framework. We walked through the installation and configuration process, ensuring compatibility with React, JSDOM, and React Testing Library. The comprehensive guide covered writing tests for custom hooks, including handling asynchronous logic, and testing React components, leveraging custom matchers for DOM assertions.

By adopting Vitest, developers can streamline the testing process for their React applications, whether powered by Vite or not. The framework's seamless integration with Vite projects simplifies the setup, reducing the complexities associated with other testing tools like Jest.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Victor Umeh
Software Engineer. Passionate about web developement with specialty in Reactjs and Nextjs. He also interested in web3 and blockchain development. In his free time he plays soccer.
@Vyktoreumeh @vyktoremario

Optimizing React Components with the React Compiler in V18

Jesse Tomchak shows viewers how to use the new React compiler to automate memoization and useCallback to optimize React components. He demonstrates the manual process of optimizing React code and then shows how the React compiler simplifies this by automatically managing these optimizations. He also demonstrates setting up and configuring the compiler in React v18 using a Babel plugin, and explores the generated output to explain how the compiler enhances performance. Chapters Introduction and Overview - 00:00 Introduction to the React Compiler - 02:27 Manual Optimization with useMemo and useCallback - 09:27 Setting Up the React Compiler - 26:00 Analyzing Compiler Output - 44:50 Exploring the Playground and Generated Code - 50:47 Handling Skipped Components and Memoization - 58:18 Discussion on React's Future and Best Practices - 01:03:28 Q&A and Audience Interaction - 01:10:53 Conclusion and Final Thoughts - 01:15:38 Follow Jesse Tomchak on Social Media Twitter: https://x.com/jtomchak Linkedin: https://www.linkedin.com/in/jtomchak/ Mastodon: https://moth.social/@jtomchak Github: https://github.com/jtomchak...

Aug 23, 2024

1 min

React

Kent C. Dodds on Why he Traded Angular for React, Launching EpicWeb.dev, + What’s Next for EpicReact.dev

Kent C. Dodds joins Tracy Lee and Rob Ocel at THAT Conference-WI for a discussion about his journey from being an Angular developer to becoming a leading figure in the React community. Kent shares his motivations for making the switch, detailing how React's focus on JavaScript fundamentals and its incremental adoption of new features appealed to him. He also reviews his current and upcoming projects, including the launch of EpicWeb.dev, a comprehensive platform designed to provide end-to-end web development education. Kent talks about the updates coming to EpicReact.dev, including a new tutorial where developers can build useState and useEffect from scratch, aimed at deepening their understanding of React hooks. Chapters 00:00 Introduction and Background 02:41 Preparing for a 90-Minute Keynote 05:37 Writing a Book and Other Projects 08:04 Surrounded by Ambitious People 09:01 Personal Stories and Balance 10:22 Lessons from Domo and Joe Eames 11:21 Learning from Experienced Engineers 12:41 The Importance of Surroundings 13:33 Choosing the Right People to Associate With 14:46 Kent's Organizational Skills 15:41 Balancing Work and Family 17:06 Committing to Big Things 18:04 Avoiding Burnout and Assessing Priorities 19:26 Sharing Personal Stories in Talks 20:21 Finding Effectiveness and Efficiency 21:17 Dealing with Burnout and Overwhelm 22:46 The Entrepreneurial Mentality 23:15 Running to the Top and Figuring It Out 24:14 Kent's Various Projects 25:41 Transitioning from Angular to React Follow Kent C Dodds on Social Media Twitter: https://x.com/kentcdodds Linkedin: https://www.linkedin.com/in/kentcdodds/ Bluesky: https://bsky.app/profile/kentcdodds.com GitHub: https://github.com/kentcdodds EpicWeb.dev: https://www.epicweb.dev/ EpicReact.dev: https://www.epicreact.dev/ Learn More About THAT Conference Wisconsin 2024: https://thatconference.com/wi/2024/ Listen to this episode here. Sponsored by Wix Studio...

Aug 14, 2024

2 mins

AngularReact

Understanding Effects In SolidJS

Understanding Effects In SolidJS In SolidJS, effects are a fundamental concept that helps developers manage side effects and reactive dependencies within their applications. Unlike standard functions that execute once and are done, effects in SolidJS are designed to automatically re-run whenever their dependencies change. This article will explore what effects are, how to use them, manage dependencies, handle multiple signals, and the lifecycle functions that enhance their functionality. What Are Effects? Effects in SolidJS are functions that automatically execute when the signals or reactive values they depend on change. This capability makes effects essential for managing side effects like DOM manipulations, data fetching, and subscriptions. Creating an Effect To create an effect in SolidJS, you use the createEffect function. This function takes a callback that runs whenever the effect is triggered by a change in its dependencies. ` In this example, the effect logs the user’s online status to the console. Each time the isOnline signal changes, the effect re-runs and logs the updated status. Managing Dependencies Dependencies in effects are the reactive values or signals that an effect observes. When any of these dependencies change, the effect re-runs. Interestingly, SolidJS automatically tracks these dependencies, meaning you don’t need to manually specify them, which reduces the risk of errors. When an effect is initialized, it runs once even if its dependencies haven't changed. This initial run is useful for setting up the effect, initializing variables, or subscribing to signals. ` Subscribing to Signals When an effect observes a signal, it essentially subscribes to it. This subscription allows the effect to re-run whenever the signal's value changes. ` In this example, the effect logs the current temperature whenever it changes. Managing Multiple Signals Effects in SolidJS can observe multiple signals simultaneously. This means that a single effect can track changes in multiple reactive values, re-running whenever any of them change. ` Here, the effect monitors both temperature and humidity signals. It re-runs when either signal changes, ensuring that it always logs the latest values. Nested Effects SolidJS allows effects to be nested within each other. Each nested effect independently tracks its own dependencies, ensuring that changes in an inner effect don’t inadvertently trigger an outer effect. ` In this example, changes to dependencies in the inner effect will not affect the outer effect. This separation prevents unintended behaviors and keeps effects isolated from one another. Lifecycle Functions SolidJS offers lifecycle functions that give you more control over when effects are initialized and disposed of. This can include running a side effect only once, or cleaning up a task when it is no longer needed. onMount The onMount function is used when you need to run a side effect only once, typically when a component is initialized. Unlike effects, which can re-run multiple times, onMount ensures that the callback is executed only once. ` This function is perfect for tasks like fetching data or setting up subscriptions that only need to happen once when the component mounts. onCleanup The onCleanup function is used to clean up tasks when a component is unmounted. This is particularly useful for clearing intervals, removing event listeners, or unsubscribing from services, thereby preventing memory leaks. ` In this example, onCleanup ensures that the interval is cleared when the component is unmounted, preventing it from running indefinitely in the background. Understanding the Execution Model of Effects in SolidJS SolidJS introduces a fine-grained reactivity) system that sets it apart in the UI development landscape. Unlike React, where effects are tied to component lifecycles and can sometimes trigger unnecessary re-renders, SolidJS operates at a much more granular level. It tracks dependencies down to individual signals or computations, enabling highly efficient updates. When you create an effect using createEffect, SolidJS automatically monitors every reactive signal accessed within that effect. It builds a precise dependency graph, which maps out exactly which effects should be re-executed when specific signals change. This approach ensures that only the necessary parts of your application update in response to state changes, resulting in more efficient rendering and overall better performance. Conclusion Effects in SolidJS are a powerful feature that enable you to react to changes in your application's state dynamically. By leveraging createEffect and using lifecycle functions like onMount and onCleanup, you can create robust and responsive applications. Understanding how to effectively use effects will help you build more efficient, maintainable, and bug-free SolidJS applications....

Aug 23, 2024

3 mins

SolidJS

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

How to test React custom hooks and components with Vitest

Introduction

Prerequisites

Installation and configuration

Writing test for custom hooks

Testing hooks with asynchronous logic

Writing test for components

Conclusion

Victor Umeh

You might also like

Optimizing React Components with the React Compiler in V18

Kent C. Dodds on Why he Traded Angular for React, Launching EpicWeb.dev, + What’s Next for EpicReact.dev

Understanding Effects In SolidJS

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

Optimizing React Components with the React Compiler in V18

Kent C. Dodds on Why he Traded Angular for React, Launching EpicWeb.dev, + What’s Next for EpicReact.dev

Understanding Effects In SolidJS

Introduction to Zod for Data Validation