blog | abelcastro.dev

Decoupling Data Fetching of This Blog

2024-08-20

typescripttestingrest-api

Currently, this blog fetches data from an external REST API. You can find more details here.

In my recent work , I focused on decoupling my components from the data source. My goal was to transition from code like this:

export default async function Home({
  searchParams,
}: {
  searchParams?: HomeSearchParams;
}) {
  const posts = await fetch("https://rest-api-url.com/");

Here, we're making a fetch call to an external REST API to retrieve post objects.

To something like this:

export default async function Home({
  searchParams,
}: {
  searchParams?: HomeSearchParams;
}) {
  const posts = await activeDataProvider.getAll();

With these changes, we introduced a new layer between data-fetching operations and the component itself. I refer to this layer as the "data provider." I defined an interface specifying the required and optional methods for a data provider:

export interface IDataProvider {
    getAll(options: PostSearchOptions): Promise<PaginatedPosts>;
    getBySlug(slug: string): Promise<Post | null>;
    create?(data: Partial<Post>): Promise<Post>;
    update?(slug: string, data: Partial<Post>): Promise<Post | null>;
    delete?(slug: string): Promise<boolean>;
}

This approach allows us to easily switch data sources in the future. For example, if we decide to fetch data directly from a database, we would simply create a new DbDataProvider that implements IDataProvider.

We would then only need to update the data-providers/active.ts file to use the new DbDataProvider:

import { DbAPIDataProvider } from './db';

const activeDataProvider = new DbAPIDataProvider();

export default activeDataProvider;

By modifying just one file (after creating the new data provider), you can change the app's persistence layer.

Another significant benefit of this approach is improved testability. Initially, I aimed to replace the active data provider with a TestDataProvider that returns hard-coded data for unit tests. I planned to inject the active data provider as a dependency into Next.js page components like this:

export default async function Home({
    dataProvider = activeDataProvider,
    searchParams,
}: HomeProps) {
    ...

This setup allowed me to pass the test data provider as a parameter to the component:

<Suspense>
 <Home searchParams={searchParams} dataProvider={testDataProvider} />
</Suspense>

While this worked well in development, I encountered errors when running next build, such as:

Type error: Page "app/page.tsx" has an invalid "default" export:
  Type "HomeProps" is not valid.
 ELIFECYCLE  Command failed with exit code 1.
Error: Command "pnpm run build" exited with 1

The issue was that Next.js components cannot accept parameters other than params or searchParams (source).

Since dependency injection was not possible, I ended up using spyOn calls in my unit tests. Although I aimed to avoid mocks and spies, I couldn't find an alternative when dependency injection wasn't feasible.

Despite this, the testability of the code improved. For example, the test case initially looked like this:

import { getPostsAndTotalPages } from "../../app/lib/fetchPosts";

test("Home page component should match the snapshot", async () => {
  const searchParams = {
    query: "",
    page: "1",
  };

  const getPostsAndTotalPagesMock = getPostsAndTotalPages as Mock;
  getPostsAndTotalPagesMock.mockResolvedValue({
    posts: generateMockPostAPIResponse().results,
    totalPages: 2,
  });

  const { container } = render(
    <Suspense>
      <Home searchParams={searchParams} />
    </Suspense>
  );

  // Access the screen first; otherwise, toMatchSnapshot will generate an empty snapshot
  await screen.findByText("Post 1");
  expect(container).toMatchSnapshot();
});

After the changes, it now looks like this:

const jsonData = JSON.parse(readFileSync('tests/test-data.json', 'utf-8'));
const memoryDataProvider = new MemoryDataProvider(jsonData);

test('Component should match the snapshot', async () => {
    const postSlug = 'post-1';
    const params = {
        slug: postSlug,
    };

    vi.spyOn(
        activeDataProvider,
        'getSinglePostFromStorage',
    ).mockImplementation(() => memoryDataProvider.getSinglePostFromStorage(postSlug));

    const { container } = render(
        <Suspense>
            <SinglePostPage params={params} />
        </Suspense>,
    );

    // Access the screen first; otherwise, toMatchSnapshot will generate an empty snapshot
    await screen.findByText('Post 1');
    expect(container).toMatchSnapshot();
});

The revised test case is now less coupled to the implementation details of fetching post data. This makes the tests more robust and simplifies future code changes.

I hope some of this can also be helpful for you. Happy decoupling! 🚀

Testing Async React Server Components in a Next.js Project

2024-08-13

typescripttestingnext.js

Testing async components in a Next.js project can be tricky, particularly when dealing with React Server Components. The challenge arises from the need to handle asynchronous data fetching and Suspense boundaries properly.

The Challenge

React Server Components allow you to fetch data on the server and send it to the client, enhancing performance by reducing the amount of JavaScript required on the client-side. However, this asynchrony introduces complexities in testing.

Having asynchronous components like this introduces some challenges when writing unit tests

export type PageSearchParams = {
	query?: string;
	page?: string;
  };
  
  export default async function Page({
	searchParams,
  }: {
	searchParams?: PageSearchParams;
  }) {
	const query = searchParams?.query || "";
	const currentPage = Number(searchParams?.page) || 1;
	const asyncData = await fetchSomeDataAsynchronously(query, currentPage);
  
	return (
		<>Do something with {...asyncData}</>
	);
  }

A common issue is that when testing async components, you might encounter empty snapshots. This is illustrated by the following example, which renders an async component but ends up with an empty snapshot:

test("This test will pass but it will generate an empty snapshot", async () => {
  const { container } = render(<Page />);
  expect(container).toMatchSnapshot();
});

The generated snapshot might look like this:

exports[`This test will pass but it will generate an empty snapshot 1`] = `<div />`;

If we try to perform some screen assertions, the test will fail. For example:

test("This test will fail because the string cannot be found", async () => {
  const { container } = render(<Page />);
  await screen.findByText("Some text in your page"); // can't be found
});

Please note that, depending on the version of Next.js you are using, you might encounter errors like this:

Error: Objects are not valid as a React child (found: [object Promise]). If you meant to render a collection of children, use an array instead.

Check the links at the end of the post to see which package versions should help avoid these errors.

The Solution: Using `<Suspense>` and `screen`

To solve this issue I discovered a workaround in this GitHub issue.

The workaround is to wrap your Component with <Suspense> to the render call. With that change the screen assert will pass.

test("This will pass but will now pass", async () => {
	const { container } = render(
		<Suspense>
			<Page />
		</Suspense>,
	);
	await screen.findByText("Some text in your page");
});

From the other side, if you are only interested in asserting the snapshot like this, the snapshot will still be empty.

test("This will pass but will still generate an empty snapshot", async () => {
	const { container } = render(
		<Suspense>
			<Page />
		</Suspense>,
	);
	expect(container).toMatchSnapshot();
});

I discovered that for some reason that I cannot understand, if you call first a screen assert the snapshot will finally generate a correct snapshot.

test("This will pass and will now generate a correct snapshot", async () => {
	const { container } = render(
		<Suspense>
			<Page />
		</Suspense>,
	);
	await screen.findByText("Some text in your page");
	expect(container).toMatchSnapshot();
});

Conclusion

As far as I understand, the issues are caused by these features being quite new and still in development, and it is possible that by the time you read this, the issue may already be resolved.

Please note that my proposed solutions are more of a workaround and may rely on unstable package versions.

In any case, I hope this helps others successfully write unit tests for asynchronous server components ✅ 🚀.

You can check the source code of this blog to see these workarounds in action within a real-world app, or review this demo project that showcases the problem with a simple app.

Happy coding! Happy testing!

Building Fasting Timer 18:6: A Learning Journey with React, Next.js, and More

2024-07-26

typescripttestingtailwind

Fasting Timer 18:6

In my journey of learning more about React and Next.js, I created a new project: Fasting Timer 18:6. In this blog post, I'll take you through the details of the project, the key learnings, and some interesting technical aspects that might be helpful for fellow developers.

You can check out the project repository here and try the live app here.

Project Overview

Fasting Timer 18:6 is a simple yet effective application designed to help users manage their intermittent fasting schedules. The 18:6 fasting method involves fasting for 18 hours and eating during a 6-hour window. This app helps users keep track of their fasting and eating times with ease.

Key Learnings

Working on this project provided me with several valuable learning opportunities:

Testing React Apps with Jest
- Writing tests for React applications was one of the primary goals of this project. Using Jest, I was able to create a comprehensive test suite to ensure the app functions correctly. Testing not only helps in catching bugs early but also makes the codebase more maintainable.
- Here's a snippet of a simple test case:

	import { render, screen, fireEvent, act } from "@testing-library/react";
	import Home from "../app/page";
	import storageService from "../app/storage/storage-service";
	
	it("should start the timer and switch to fasting/eating mode after clicking the button", async () => {
    	const { container } = render(<Home />);
    	
    	expect(container).toMatchSnapshot();
    	
    	// Start fasting
    	const button = screen.getByRole("button", { name: /Start fasting/i });
    	await act(async () => {
    	  fireEvent.click(button);
    	});
    	
    	expect(container).toMatchSnapshot();
    	
    	const startFastingTime = storageService.getStartFastingTime();
    	expect(startFastingTime).toBeInstanceOf(Promise<Date>);
    	// ...
	});

Creating a Coverage Badge with Codecov.io
- Integrating Codecov.io allowed me to monitor test coverage. This step was crucial in ensuring that a significant portion of the code is tested, providing a clear picture of areas that might need more attention.
- The coverage badge is prominently displayed in the repository, serving as a quick reference for the project's test coverage status.

The StorageService Concept

One of the interesting aspects of the project is the StorageService. This service is designed to manage the storage and handling of fasting and non-fasting times.

Key Points:

BrowserStorage as Default Provider: Currently, the default storage provider is BrowserStorage, which stores data in the user's local browser storage.
IStorageProvider Interface: To make the storage service flexible, an IStorageProvider interface is defined. This interface outlines the necessary methods that any storage provider must implement.
Ease of Changing Persistence Layer: With this setup, changing the persistence layer (e.g., from local storage to a database) becomes straightforward. One only needs to implement the IStorageProvider interface and update the storage service configuration.

Example Implementation:

const storageService = new StorageService(new BrowserStorageProvider());

export default storageService;

With this design, changing the persistence layer is as simple as touching two files—implementing the new storage provider and updating the configuration.

Conclusion

Working on the Fasting Timer 18:6 project has been an enriching experience. From learning to write tests with Jest to creating a flexible storage solution, each step has contributed to my growth as a developer. I hope this blog post provides valuable insights and encourages you to explore and implement these concepts in your projects.

Feel free to check out the repository, try the app, and provide any feedback or contributions. Happy coding!

Try the live app here.

...

Decoupling Data Fetching of This Blog

Testing Async React Server Components in a Next.js Project

The Challenge

The Solution: Using <Suspense> and screen

Conclusion

Building Fasting Timer 18:6: A Learning Journey with React, Next.js, and More

Project Overview

Key Learnings

The StorageService Concept

Conclusion

The Challenge

The Solution: Using <Suspense> and screen

Conclusion

Project Overview

Key Learnings

The StorageService Concept

Conclusion

The Solution: Using `<Suspense>` and `screen`

The Solution: Using `<Suspense>` and `screen`