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

Why is My React Reducer Called Twice and What the Heck is a Pure Function?

Why is My React Reducer Called Twice and What the Heck is a Pure Function? In a recent project, we encountered an interesting issue: our React reducer was dispatching twice, producing incorrect values, such as incrementing a number in increments of two. We hopped on a pairing session and started debugging. Eventually, we got to the root of the problem and learned the importance of pure functions in functional programming. This article will explain why our reducer was being dispatched twice, what pure functions are, and how React's strict mode helped us identify a bug in our code. The Issue We noticed that our useReducer hook was causing the reducer function to be called twice for every action dispatched. Initially, we were confused about this behavior and thought it might be a bug in React. Additionally, we had one of the dispatches inside a useEffect, which caused it to be called twice due to React strict mode, effectively firing the reducer four times and further complicating our debugging process. However, we knew that React's strict mode caused useEffect to be called twice, so it didn't take very long to realize that the issue was not with React but with how we had implemented our reducer function. React Strict Mode React's strict mode is a tool for highlighting potential problems in an application. It intentionally double-invokes specific lifecycle methods and hooks (like useReducer and useEffect) to help developers identify side effects. This behavior exposed our issue, as we had reducers that were not pure functions. What is a Pure Function? A pure function is a function that: - Is deterministic: Given the same input, always returns the same output. - Does Not Have Side Effects: Does not alter any external state or have observable interactions with the outside world. In the context of a reducer, this means the function should not: - Modify its arguments - Perform any I/O operations (like network requests or logging) - Generate random numbers - Depend on any external state Pure functions are predictable and testable. They help prevent bugs and make code easier to reason about. In the context of React, pure functions are essential for reducers because they ensure that the state transitions are predictable and consistent. The Root Cause: Impure Reducers Our reducers were not pure functions. They were altering external state and had side effects, which caused inconsistent behavior when React's strict mode double-invoked them. This led to unexpected results and made debugging more difficult. The Solution: Make Reducers Pure To resolve this issue, we refactored our reducers to ensure they were pure functions. Here's an extended example of how we transformed an impure reducer into a pure one in a more complex scenario involving a task management application. Let's start with the initial state and action types: ` And here's the impure reducer similar to what we had initially: ` This reducer is impure because it directly modifies the state object, which is a side effect. To make it pure, we must create a new state object for every action and return it without modifying the original state. Here's the refactored pure reducer: ` Key Changes: - Direct State Modification: In the impure reducer, the state is directly modified (e.g., state.tasks.push(action.payload)). This causes side effects and violates the principles of pure functions. - Side Effects: The impure reducer included side effects such as logging and direct state changes. The pure reducer eliminates these side effects, ensuring consistent and predictable behavior. I've created an interactive example to demonstrate the difference between impure and pure reducers in a React application. Despite the RESET_TASKS action being implemented similarly in both reducers, you'll notice that the impure reducer does not reset the tasks correctly. This problem happens because the impure reducer directly modifies the state, leading to unexpected behavior. Check out the embedded StackBlitz example below: Conclusion Our experience with the reducer dispatching twice was a valuable lesson in the importance of pure functions in React. Thanks to React's strict mode, we identified and fixed impure reducers, leading to more predictable and maintainable code. If you encounter similar issues, ensure your reducers are pure functions and leverage React strict mode to catch potential problems early in development. By embracing functional programming principles, you can write cleaner, more reliable code that is easier to debug and maintain....

Jun 14, 2024

3 mins

React

Quick Guide to Playwright Fixtures: Enhancing Your Tests

Introduction Following our recent blog post on migrating E2E tests from Cypress to Playwright, we've identified opportunities to enhance our test scripts further. In this guide, we'll delve into the basics of Playwright fixtures, demonstrating their utility and flexibility in test environments. Playwright fixtures are reusable components that set up and tear down the environment or conditions necessary for tests. They are crucial for writing clean, maintainable, and scalable tests. Fixtures can handle tasks like opening a browser, initializing a database, or logging into an application—actions you might need before running your tests. As a practical example, we'll revisit one of the tests from our previous post, enhancing it with a new fixture to streamline the testing process and significantly improve maintainability. This post is designed to provide the foundational skills to integrate fixtures into your testing workflows effectively, giving you the confidence to manage and maintain your test scripts more efficiently. Creating Our First Fixture To illustrate the power of fixtures in Playwright, let’s consider a practical example from a test scenario in our project. Below is a snippet of a test case from our newsletter page: ` This test scenario navigates to the newsletter page, fills in an email, submits the form, and checks for a success message. To optimize our test suite, we'll refactor common actions like navigation, form completion, and submission into reusable fixtures. This approach makes our tests cleaner and more maintainable and reduces redundancy across similar test scenarios. Implementing the Fixture Here’s how the fixture looks: ` This fixture encapsulates the actions of navigating to the page, filling out the email field, and submitting the form. By abstracting these actions, we simplify and focus our test cases. Refactoring the Test With the fixture in place, let’s see how it changes our original test file: ` A beforeEach method to reset the state of the NewsletterPage fixture ensures a clean and consistent environment for each test scenario. This practice is crucial for maintaining the integrity and reliability of your tests. By leveraging the NewsletterPage fixture, each test within the "Newsletter page" suite starts with a clean and pre-configured environment. This setup improves test clarity and efficiency and aligns with best practices for scalable test architecture. Conclusion As we've seen, fixtures are powerful tools that help standardize test environments, reduce code redundancy, and ensure that each test operates in a clean state. By abstracting common setup and teardown tasks into fixtures, we can focus our testing efforts on what matters most, verifying the behavior and reliability of the software we're developing. Remember, the key to successful test management is choosing the right tools and using them wisely to create scalable, maintainable, and robust testing frameworks. Playwright fixtures offer a pathway towards achieving these goals, empowering teams to build better software faster and more confidently....

Jul 26, 2024

2 mins

Testing

File Based Routing with Expo Router

Introduction If there is one thing most Javascript developers love, it is file-based routing, and with the advent of frameworks like Next.js, this form of routing has become more popular and most preferred when building applications. The React Native community will not be left out, as earlier this year, Expo released the Expo router, which implements the file-based routing convention. Currently, the Expo router is in V2, which is supported by version 49 of the Expo SDK. In this article, we will take a look at the features that the Expo router offers and explore its file-based routing system. What is Expo Router? Expo Router is a file-based router for React Native and web applications. It allows you to manage navigation between screens in your app, allowing users to move seamlessly between different parts of your app's UI, using the same components on multiple platforms (Android, iOS, and web). It brings the best file-system routing concepts from the web to a universal application, allowing your routing to work across every platform. When a file is added to the app directory, the file automatically becomes a route in your navigation. Features of Expo Router - Native: It is built on the React Navigation suite, Expo Router navigation is truly native and platform-optimized by default. - Shareable: Every screen in your app is automatically deep linkable, making any route in your app shareable with links. - Offline-first: Handles all incoming native URLs without a network connection or server. Apps are cached and run offline first, with automatic updates when you publish a new version. - Optimized: Routes are automatically optimized with lazy evaluation in production and deferred bundling in development. - Iteration: Universal Fast Refresh across Android, iOS, and the web, along with artifact memoization in the bundler to keep you moving fast at scale. - Universal: Android, iOS, and web share a unified navigation structure, with the ability to drop down to platform-specific APIs at the route level. - Discoverable: Expo Router enables build-time static rendering on the web and universal linking to native. Meaning your app content can be indexed by search engines. Expo routing conventions Let’s build a simple application to discuss the various routing conventions and explore some features of the Expo router. To get started, all you need to do is run the following command ` This will create a bare-bone expo project with an Expo router. By default, it is not configured to use typescript. To add a typescript to the project, go to the root of the project and run: ` Expo also provides a way to create a minimal project with the Expo Router library already installed. To create a project, run the command: ` For this article, we will stick with the first approach. Route navigation Now let’s create our first page. Create a file called app/index.tsx and add the following code: ` From the above code, we see that the expo router provides a Link component for navigation. This is very familiar to how the web works with anchor tag and the href attribute. The Link component wraps the children in a component by default; this is useful for accessibility but not always desired. You can customize the component by passing the asChild prop, which will forward all props to the first child of the Link component. The child component must support the onPress and onClick props, href and accessibilityRole will also be passed down. Additionally, we can also use the useRouter hook to navigate to a route. This is very useful if navigating from a global store or custom hook. Layout Routes At the moment, any page we create covers the whole screen, and this is not perfect in most native apps. In that case, we can define a layout that will wrap our pages and add a header and footer, or in our case, a native stack component. This follows the same approach as the usual React Native stack, and we can define the different screens based on their file name. Let’s create a root layout app/_layout.tsx file: ` From the above code, we added the native stack component to define the different screens on the app. We also added screenOptions to add some basic header styles This is useful if you want to define the layout style for all routes. You can also change the layout for each screen by adding various style options to the options property in the component. Furthermore, if you create a directory that groups different routes, you can create a layout for those routes. Unmatched Routes From our example above, we do not have a register page, so if we try to click on the link and visit that page, we will get an unmatched error page. Expo router provides a default unmatched route. This is the fallback page when you try to reach a route that does not exist. You can customise this route by creating a file called app/[...unmatched].tsx and exporting any component you want to render instead. Be sure to have a link to ‘/’ so users can navigate back to the home screen. Groups Groups are used to organize sections of the app. When we wrap a directory name in parenthesis (e.g., (profile)), it does so without adding segment to the URL. This is mostly useful when you are developing for the web, and you don’t want the group name to exist as a segment on the URL. Let’s create a group named (tabs). This will contain two tab files: home and account. Create a file name apps/(tabs)/home.tsx and add the following code: ` Create another file called apps/(tabs)/account.ts and add the following code: ` We can now add a layout to the (tabs) group. The layout won’t use a component but will use a component. Create a _layout.tsx file inside the (tabs) directory and add the following code: ` From the above code, we created two tabs for the Home page and the Account page. We added the appropriate icons for those tabs. On the homepage, we added a Logout link. In the Link component, we added a replace attribute because using the Link component is almost the same as calling router.push(). It adds the route on top of the stack. But since this is a Logout link, we need to replace all existing navigation stacks with the route. By default, you should be able to navigate to the tabs screen, but you will notice that it has multiple header sections as seen below: You will notice that there are two header sections. The first header with the title (tabs) is inferred by the Expo router, and it uses the styling from the root layout. The second header was created when we added some options in the component. We can remove any of the headers depending on our app design. To remove the first header, we must add the (tabs) route as a screen to the root layout and set the headerShown to false. So go to the _layout.tsx file on the root of the app directory and add the following code: ` We are setting the headerShown to false because the (tabs) group also has a layout, and each tab on the layout has an option that sets the headerTitle and other header properties. That is the header we would show, as they will change for the different tabs. If we want a static header for both tabs, we can add headerShown: false to all tabs options on the tab layout. Shared routes To match the same URL with different layouts, use groups with overlapping child routes. This pattern is very common in native apps. For example, in the Twitter app, a profile can be viewed in every tab (such as home, search, and profile). However, there is only one URL that is required to access this route. Here is an example of how a shared route is structured: Shared routes can be navigated directly by including the group name in the route. For example, /(search)/victor navigates to /victor in the "search" layout. Kindly note that for web apps, when you directly type/victor on your browser, the Expo router cannot tell which [user].tsx you are trying to reach, so it gets the first route that matches the path from your file tree (In the case above, it is the (home)/[user].tsx). Shared routes are most useful in tab navigations because it is easier to know the group from which the route was visited and keep the tab active. Arrays Instead of defining the same route multiple times with different layouts, we can use the array syntax (,) to duplicate the children of a group. For example, app/(home,profile,search)/[user].tsx creates app/(home)/[user].tsx, app/(profile)/[user].tsx and app/(search)/[user].tsx in memory. To distinguish between the two routes, use a layout's segment prop: ` Dynamic Route Dynamic routes match any unmatched path at a given segment level. For example, if I have a directory named contacts, I can create a dynamic route for each contact app/contacts/[slug].tsx. This is very useful if you have a list of contacts and you want to show the details of one contact. Routes with higher specificity will be matched before a dynamic route. For example, contacts/victor will match app/contacts/victor.tsx before app/contacts/[user].tsx. Multiple slugs can be matched in a single route using the rest of the syntax (...). For example, app/contacts/[…rest].tsx matches /contacts/123/settings. Dynamic segments are accessible as search parameters in the page component. ` Conclusion In this article, we learned about the Expo Router, how it works, its core features, and its tradeoffs using some example codes. Expo Router offers a minimalistic API with a straightforward approach to navigation using the file-system routing concepts. The Expo router is most useful if you are not dealing with a complex navigation system in your project. File-based routing provides a smooth navigation experience for mobile applications, and Expo Router implements this solution into its library....

Jan 10, 2024

8 mins

ReactExpoReact Native

Svelte 5 is Here!

Svelte 5 was finally released after a long time in development. Fortunately, we've been able to test it for some time, and now it has a stable release. Let's dig into its features and why this is such a significant change, even though Svelte 4 code is almost 100% compatible. Svelte syntax everywhere This is one of my favorite additions. Previously, Svelte syntax was limited to a component element. Refactoring code from a component and moving it to a JavaScript file worked differently. Now you can use the .svelte.js or .svelte.ts extension, which allows you to use the same syntax everywhere. It's important to note that it's a way to express that this is not just JS, and what you write may be compiled to something else, just like .svelte files are not just html even though they look very similar. Runes The introduction of runes is one of the most significant changes in Svelte. Many users felt attracted to variables being instantly reactive in previous versions. ` There was, however, a lot of magic underneath and a considerable amount of work from the compiler to make it behave reactively. $state In Svelte 5, a reactive variable has to be explicitly declared using the $state rune, which brings a clear distinction between what is reactive and what isn’t. ` In the previous code, $state is not an actual function being called; it's a hint for the compiler to do something special with this declaration. Rune names always start with a dollar sign ($) and do not need to be imported. However, there’s much more to the changes than just the way we declare reactive variables. Runes bring a lot of new features that make Svelte 5 a great improvement. In Svelte 5, objects or arrays use Proxies to allow for granular reactivity, meaning that individual properties in an object are reactive, even if they are nested objects or arrays. If you modify a property, it will only update that property and will not trigger an update on the whole object. It also supports triggering updates when methods like array.push are called. In previous versions, an assignment was required to trigger an update: ` To have a similar behavior of svelte 4 (no deep reactivity), use the $state.raw() rune. This syntax of .* is common for related features of a rune: $state.raw() will require an assignment to trigger reactivity. ` Because proxies are used, you may need to extract the underlying state instead of the proxy itself. In that case, $state.snapshot() should be used: ` $derived We will use $derived and $derived.by to declare a derived state. The two runes are essentially the same, except one allows us to use a function instead of an expression, allowing for more complex operations to calculate the derived values. ` $effect Effects are useful for running something triggered by a change in state. One of the things you'll note from the $effect rune is that dependencies don't need to be explicit. Those will be picked from reactive values read synchronously in the body of the effect function. ` Something to bear in mind is that these dependencies are picked each time the effect runs. The values read during the last run become the dependencies of the effect. ` Depending on the result of the random method, foo or bar will stop being a dependency of the effect. You should place them outside the condition so they can trigger reruns of the effect. *Variants* of the effect rune are $effect.pre, which runs before a DOM update, and $effect.tracking(), which checks for the context of the effect (true for an effect inside an effect or in the template). $props This rune replaces the export let keywords used in previous versions to define a component's props. To use the $props syntax, we can consider it to return an object with all the properties a component receives. We can use JavaScript syntax to destructure it or use the rest property if we want to retrieve every property not explicitly destructured.. ` $bindable If you want to mutate a prop so that the change flows back to the parent, you can use the $bindable prop to make it work in both directions. A parent component can pass a value to a child component, and the child component is able to modify it, returning the data back to the parent component. ` $inspect The $inspect rune only works in dev mode and will track dependencies deeply. By default, it will call console.log with the provided argument whenever it detects a change. To change the underlying function, use $inspect.with().with): ` $host The host rune gives access to the host element when compiling as a custom element: ` ` Other changes Another important change is that component events are just props in Svelte 5, so you can destructure them using the $props() rune: ` A special children property can be used to project content into a component instead of using slots. Inside the components, use the [@render[(https://svelte.dev/docs/svelte/@render) tag to place them. ` Optional chaining (?.) prevents from attempting to render it if no children are passed in. If you need to render different components in different places (named slots before Svelte 5, you can pass them as any other prop, and use @render with them. Snippets Snippets allow us to declare markup slices and render them conveniently using the render tag (@render). They can take any number of arguments. ` Snippets can also be passed as props to other components. ` ` Conclusion Some exciting changes to the Svelte syntax were introduced while, at the same time, maximum compatibility efforts were made. This was a massive rewrite with numerous improvements in terms of performance, bundle size, and DX. Besides that, a new CLI has been released, making the whole experience of starting a project or adding features delightful. If you haven't tried Svelte before, it's a great time to try it now....

Nov 27, 2024

4 mins

Svelte

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

Why is My React Reducer Called Twice and What the Heck is a Pure Function?

Quick Guide to Playwright Fixtures: Enhancing Your Tests

File Based Routing with Expo Router

Svelte 5 is Here!

Let's innovate together!

You might also like

Why is My React Reducer Called Twice and What the Heck is a Pure Function?

Quick Guide to Playwright Fixtures: Enhancing Your Tests

File Based Routing with Expo Router

Svelte 5 is Here!