DEV Community: Nikita Bogachenkov

Dive into Next.js Parallel & Intercepting Routing: Enhancing UX

Nikita Bogachenkov — Fri, 11 Oct 2024 11:00:00 +0000

In this final part of our series, we dive into two incredibly powerful features of Next.js—parallel routes and intercepting routes. These tools allow you to drastically improve the user experience by dynamically loading data and seamlessly switching between different parts of your app. Whether you’re building dashboards, e-commerce sites, or complex interfaces with lots of interactive components, these features can be game-changers in optimizing your application.

Parallel Routes

Parallel routes in Next.js are like having multiple independent UI components working together at the same time. Imagine you have a dashboard where one column shows categories and another shows products. Each component can update independently, improving the user experience by reducing unnecessary reloads and enhancing interface responsiveness.

To implement parallel routes, Next.js uses the naming convention @folder, and these folders are called slots. These slots are passed as props to the parent layout, and each slot can render its own part of the page.

Let’s break this down with an example: you have a dashboard with two slots—one for categories, the other for products. When you select a product from the list, we can open its edit page in the same slot.

Here’s what the structure of our dashboard would look like:

Now, let’s see how we can implement this in layout.tsx. Each slot is automatically passed to the layout as a prop, which you can use for rendering:

export default function DashboardLayout({
  children,
  categories,
  products
}: {
  children: React.ReactNode;
  categories: React.ReactNode;
  products: React.ReactNode;
}) {
  return (
    <div>
      {children}
      <div className='grid grid-cols-2 gap-10'>
        <div>
          {categories}
        </div>
        <div>
          {products}
        </div>
      </div>
    </div>
  );
}

One important thing to note: slots are not route segments, so they don’t affect the URL structure in any way.

Benefits of Parallel Routes

Independent Loading

Each slot manages its own loading state or error handling. This is especially useful when different parts of a page load at varying speeds.

Support for Subnavigation

Each slot is a self-contained unit that can have its own navigation. For example, the @products slot can have a subroute [id] for displaying product details. When you select a product with id: 1, the URL changes to /dashboard/1. You might expect it to be something like /dashboard/products/1 or /dashboard/@products/1, but remember—slots don’t affect the URL.

When you navigate to /dashboard/1, Next.js checks which slots correspond to this route. In this case, it matches the products slot, and the rest are considered missing. What happens next depends on the type of navigation.

Soft and Hard Navigation

With soft navigation (e.g., clicking within the interface), only parts of the UI are updated, providing a smoother user experience. In this case, Next.js retains the state of slots regardless of URL changes. For example, when navigating to /dashboard/1, the categories slot and the main page remain unchanged.

Hard navigation (e.g., refreshing the page) causes a full reload, resetting the state of all slots. If a slot doesn’t match the URL, Next.js renders the default.tsx file for that slot. If there’s no default.tsx, you’ll see a 404 error.

You can use default.tsx to display static content or even replicate some logic from page.tsx. For example, in the above case, I replaced parts of the unchanged page.tsx with default.tsx (and it works perfectly).

When to Use Parallel Routes?

Parallel routes are ideal for complex UIs where multiple parts of the page need to update without a full reload. Dashboards are the classic use case, but the possibilities don’t end there. You can render article comments alongside the content or display multiple steps of a form on a single screen.

A particularly interesting use case is conditional routes, where slot rendering depends on specific conditions:

import { getUserRole } from "@/utils/auth";

export default function Layout({
  admin,
  manager,
  user
}:{
  admin: React.ReactNode,
  manager: React.ReactNode,
  user: React.ReactNode
}) {
  const userRole = getUserRole();

  switch (userRole) {
    case "admin":
      return admin;
    case "manager":
      return manager;
    case "user":
      return user;
    default:
      return <div>No user role</div>
  }
}

But this isn’t the end of the road. When combined with intercepting routes, parallel routes unlock even more powerful ways to handle the same URL, offering different rendering experiences.

Intercepting Routes: Adding Context to Navigation

Intercepting routes in Next.js are like a secret trick for enhancing user interactions. Imagine a user browsing through a product catalog and clicking on a product. Instead of redirecting them to a separate page, we can open a modal window without disrupting the context of the current page. This isn’t just a convenience—it’s a significant upgrade to the user experience.

But how does Next.js know when to show a modal versus a full page? This is where intercepting route notations come into play. Let’s break down how they work.

Intercepting Route Notations

Special symbols like (.), (..), and (...) allow you to control route behavior as if you’re navigating through a file system. These notations provide flexibility in how your application renders pages:

(.)folder — Intercept the route at the same level
(..)folder — Intercept the route one level up
(..)(..)folder — Two levels up, and so on
(...)folder — Intercept from the root level

Keep in mind: (folder) groups and @folder slots are not route segments. This means they don’t count towards the depth of the route’s nesting.

How Does This Work in Practice?

Imagine the user is on the /catalog page and clicks on a product with the URL /products/chair-4. If this route is intercepted, Next.js will open the product details in a modal window, while the catalog remains visible in the background. However, if the user navigates to this URL directly, they’ll see a full product page:

In the layout.tsx for the catalog, we can add an additional prop for the modal window:

export default function CatalogLayout({
  children,
  modal
}: {
  children: React.ReactNode;
  modal: React.ReactNode;
}) {
  return (
    <div>
      {children}
      {modal}
    </div>
  );
}

And here’s how the layout.tsx for the modal might look:

import ProductPage from '@/app/products/[slug]/page';
import ProductModal from '@/components/ProductModal';
import React from 'react';

interface LayoutProps {
  children?: React.ReactNode;
  params: { slug: string };
}

const ModalLayout: React.FC<LayoutProps> = ({
  params
}) => {
  return (
    <ProductModal>
      <ProductPage params={params} />
    </ProductModal>
  )
};

export default ModalLayout;

Since both the product page and modal content are the same, we simply return the main page from the layout to avoid code duplication.

Why Does This Matter?

Intercepting routes make interfaces more flexible and adaptive. Instead of burdening users with full page reloads, you can dynamically load content while maintaining the current context. This is especially important in applications like e-commerce, where users may want to view multiple products and easily switch between them.

Flexibility and Benefits

By combining intercepting and parallel routes, you can build complex, interactive interfaces where the user retains control of their environment. For instance, you can render multiple blocks simultaneously and manage their states independently. All of this, while preserving context and minimizing reloads.

Tools like parallel and intercepting routes provide developers with the means to create applications that offer smoother navigation and an improved user experience. Leveraging these features allows you to simplify routing while boosting performance and responsiveness. These capabilities extend Next.js’s potential, empowering you to build not just apps but truly modern, dynamic interfaces that seamlessly adapt to user needs.

This wraps up our dive into Next.js and its tools for rendering and routing! We began with the fundamentals of Server Side Rendering, explored the intricacies of server components and actions, delved into the App Router, and now, we’ve concluded with parallel and intercepting routes. These tools not only improve performance and UX but also unlock new possibilities for building scalable, flexible, and responsive applications.

Each topic we covered offers unique opportunities for developers, and together, they provide everything you need to create modern applications with Next.js. May these insights help you build projects that delight users and exceed expectations!

Dive into Next.js App Router: Building Dynamic, Nested, and Static Pages

Nikita Bogachenkov — Thu, 10 Oct 2024 12:00:00 +0000

Meet the App Router: A New Era of Routing in Next.js

Now that we've explored how server components work, it’s time to see them in action within the Next.js framework. Enter the App Router—the centerpiece of the new architecture in Next.js.

The App Router is designed to merge the best of both worlds: server and client components, all within a single route. This isn’t just an upgrade from the old Pages Router—it’s a complete overhaul that allows you to manage rendering more flexibly and significantly boost performance.

With the App Router, you can combine server-side rendering with client-side interactivity, reducing server requests and improving the overall performance of your application. Let’s dive into how it works and why this approach is a game-changer in routing.

A Brief History: Pages Router vs. App Router

When Next.js first gained popularity, the Pages Router became the go-to routing solution. Every file in the pages/ directory automatically received a corresponding URL—a simple, intuitive approach that allowed developers to quickly spin up applications. There was no need to think about routes: just add a file, and you were good to go.

But as projects grew and became more complex, some limitations started to appear:

Limited flexibility: The Pages Router offered a linear routing structure, which sometimes made it hard to manage code splitting and rendering efficiently.
State and rendering management: Even with support for SSR and SSG, the Pages Router required separate API endpoints for server-side data handling, adding unnecessary complexity when dealing with both client and server logic.

Despite these drawbacks, the Pages Router was convenient for those who wanted to get up and running quickly with Next.js.

App Router: A Different Approach

The introduction of the App Router brought a new wave of possibilities. It's important to understand that this isn’t just a replacement for the Pages Router—it’s a completely different approach to solving the same problems, with more flexible tools. With it, you can combine server and client components and dynamically split code without being limited by file structure.

Here are a few key changes:

Component flexibility: Now, each route is more than just a file—it’s a component that can merge server-side and client-side rendering depending on performance and SEO needs.
Server Actions: A new feature that lets you call server functions directly from components, simplifying data handling and eliminating the need for separate API endpoints.

So, the App Router isn’t necessarily the "better" choice, but it’s certainly more flexible. It gives you more control over rendering and state management, offering tools that are better suited for building complex and scalable applications.

App Router File Structure: Layouts, Pages, Error Handling, and More

Next.js’ App Router offers a more powerful and flexible system for managing page rendering and handling various user interface scenarios. Unlike the Pages Router, which had a straightforward approach to routing, the App Router introduces a set of files that help create a more sophisticated app structure, enhancing both performance and user interaction. Let’s break down the key file types used in the App Router.

`layout.tsx` — Page Layouts

Every route in the App Router can have its own layout component. This file defines the main structure of the page, which persists while navigating through nested routes. Layouts are perfect for defining persistent UI elements (like headers or footers) that remain unchanged while the page content swaps out.

Example of layout.tsx usage:

// app/products/layout.tsx
export default function ProductsLayout({ children }: { children: React.ReactNode }) {
  return (
    <div>
      <header>Products Header</header>
      <main>{children}</main>
      <footer>Products Footer</footer>
    </div>
  );
}

In this example, when navigating between pages within /products, the header and footer stay fixed, while the content in main dynamically changes based on the route.

`page.tsx` — Page Component

Each page.tsx file is a component that renders for a specific route. It’s the primary file for outputting UI and data to a page.

Example of usage:

// app/products/page.tsx
export default function ProductsPage() {
  return <div>Products List</div>;
}

`loading.tsx` — Loading Indicator

This file is used to display a loading indicator while data is being fetched. It improves UX by showing users that something is happening instead of leaving them with a blank screen.

Example:

// app/products/loading.tsx
export default function Loading() {
  return <div>Loading products...</div>;
}

`not-found.tsx` — Not Found Page

This component renders when a route isn’t found. For example, if a user tries to access a product that doesn’t exist in the database, they’ll see a "Product not found" message.

Example:

// app/products/not-found.tsx
export default function NotFound() {
  return <div>Product not found</div>;
}

`error.tsx` — Local Error Handling

If an error occurs while rendering a specific route, the error.tsx component will display instead of the usual UI. It helps handle local errors, such as data-fetching failures.

Example:

// app/products/error.tsx
export default function Error({ error, reset }: { error: Error; reset: () => void }) {
  return (
    <div>
      <p>Something went wrong: {error.message}</p>
      <button onClick={reset}>Try again</button>
    </div>
  );
}

`global-error.tsx` — Global Error Handling

This component is for capturing errors at the application level. If an unexpected error occurs that isn’t tied to a specific route, global-error.tsx provides a user-friendly error message.

`route.ts` — API Endpoints

The route.ts file is used to create server-side API endpoints directly within the app directory. This allows you to manage server requests without leaving the routing structure.

Example:

// app/products/route.ts
export async function GET() {
  const products = await getProducts();
  return new Response(JSON.stringify(products));
}

`template.tsx` — Layout Re-rendering

This file behaves similarly to layout.tsx, but with an important difference: it re-renders every time you navigate between routes, unlike layout, which stays static.

`default.tsx` — Parallel Route Fallback

When using a parallel route and a specific segment is missing, default.tsx serves as a fallback component to display the default UI.

Example:

// app/products/(category)/default.tsx
export default function DefaultCategory() {
  return <div>Please select a category</div>;
}

This component is useful when no specific route is selected, and you need to show a default interface.

These files create a more modular and flexible app structure, giving developers greater control over rendering, state management, and error handling. The App Router is a powerful tool for building complex applications with optimized user interfaces, such as your e-commerce store, where different pages use various layouts and dynamic parameters.

The `app` Directory Structure: Grouping, Dynamic Routes, and Routing

The app/ directory in Next.js App Router provides a flexible and powerful system for organizing routes and components. Unlike the Pages Router, the App Router lets you structure your application more thoughtfully and efficiently using groupings, dynamic segments, private folders, and special routes. Let’s dive into the key elements of this system.

Route Grouping - `(folder)`

Route grouping using parentheses allows you to organize your code more logically without affecting the URL. This is particularly useful when you want to structure related components or routes without changing their final paths.

For instance, a (home) group organizes the homepage components without changing the main / route, while a (category) group organizes routes for product categories (like /products/electronics, /products/furniture), keeping your code clean and structured.

Dynamic Routes

Dynamic routes allow you to render pages with variable parameters in the URL. In Next.js, this is done using square brackets, making routing flexible and easy to work with.

`[folder]` — Dynamic Segment:

For example, the route /products/[slug] can be used to render a specific product page where slug is a dynamic parameter (like lamp).

// app/products/[slug]/page.tsx
export default function ProductPage({ params }: { params: { slug: string } }) {
return <div>Product slug: {params.slug}</div>;
}

`[...folder]` — Catch-all Segment:

It captures multiple levels of the route. For instance, the route /products/[...slug] will handle /products/electronics/tv/123, capturing the parameters as ['electronics', 'tv', '123'].

`[[…folder]]` — Optional Catch-all Segment:

This handles routes both with and without parameters. For example, /products/[[...slug]] works for /products as well as /products/electronics/tv/123.

`_folder` - Private Folders

Folders prefixed with _ are excluded from routing, allowing you to store utilities or helper files without exposing them to public routes.

Next.js also supports parallel and intercepted routes, which we’ll cover in more detail in the next section.

Params & Search Params: Managing URLs on the Fly

When it comes to working with dynamic URLs in Next.js, the App Router provides two powerful tools—Params and Search Params. These mechanisms help you pass parameters through URLs and handle them in your components, making your pages more dynamic and interactive.

Params: Dynamic URL Segments

One of the most common scenarios is working with dynamic URL segments. Imagine you have a product page, and you need to pass the product ID through the URL. In App Router, you can easily achieve this using Params.

For example, if you have a route for a specific product:

/products/[id]

You can now access this id inside your component:

// app/products/[id]/page.tsx
type ProductPageProps = {
  params: { id: string };
};

export default function ProductPage({ params }: ProductPageProps) {
  const { id } = params;

  return <div>Product ID: {id}</div>;
}

When a user navigates to /products/123, the component receives id = 123, meaning you can easily fetch and display the correct product on the page. All you need is the parameter.

Search Params: Query Parameters in the URL

But what if you need to add filtering or sorting? That’s where search parameters, or Search Params, come into play. They let you pass additional data through the query string.

Here’s an example of a URL with search parameters:

/products?category=electronics&sort=price

By using useSearchParams in the App Router, you can access these parameters:

// app/products/page.tsx
import { useSearchParams } from 'next/navigation';

export default function ProductsPage() {
  const searchParams = useSearchParams();
  const category = searchParams.get('category');
  const sort = searchParams.get('sort');

  return (
    <div>
      <h1>Products</h1>
      <p>Category: {category}</p>
      <p>Sort by: {sort}</p>
    </div>
  );
}

As a result, if a user navigates to /products?category=electronics&sort=price, the component displays the "electronics" category and sorts products by price. Simple and effective.

Combo: Params + Search Params

Now imagine a more complex scenario: you want to combine dynamic URL segments with search parameters. For example, on a product page, you need to pass both the product id and filter the reviews:

/products/[id]?filter=positive

Here’s how you can implement this:

// app/products/[id]/page.tsx
import { useSearchParams } from 'next/navigation';

type ProductPageProps = {
  params: { id: string };
};

export default function ProductPage({ params }: ProductPageProps) {
  const searchParams = useSearchParams();
  const filter = searchParams.get('filter');

  return (
    <div>
      <h1>Product ID: {params.id}</h1>
      <p>Filter: {filter}</p>
    </div>
  );
}

Now your component handles both the dynamic id for the product and the filter for reviews. This way, users can see the product page with only positive reviews, just by passing parameters through the URL.

Full Control Over Every Aspect of the URL

The combination of Params and Search Params gives you incredible flexibility in managing URLs. It allows you to change displayed data on the fly, enhancing the user experience. Ultimately, the App Router in Next.js makes managing parameters an intuitive and powerful tool for building dynamic, responsive pages.

Static Rendering vs. ISR in Pages Router & App Router

When working with Pages Router and App Router in Next.js, the approaches to handling static data and incremental static regeneration (ISR) may appear similar, but there are key differences worth noting.

Let’s start with an example where we fetch product data using Supabase:

import { QueryData, createClient } from "@supabase/supabase-js";

export const getProduct = async ({ slug }: Params) => {
  const supabase = createClient<Database>(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
  );
  const productDetailedQuery = supabase
    .from("products")
    .select()
    .eq("slug", slug)
    .single();

  console.log("Fetching product");
  const { data, error } = await productDetailedQuery;

  if (error) {
    throw new Error(error.message);
  }
  return data as ProductWithCategory;
};

Pages Router: Static Rendering and ISR

In the Pages Router, static methods like getStaticPaths and getStaticProps structure the process. It’s predictable and straightforward—you generate all possible routes ahead of time and cache the data at build time.

export const getStaticPaths = async () => {
  const { data: products } = await supabase
    .from("products")
    .select("slug");

  const paths = products.map(product => ({
    params: { slug: product.slug }
  }));

  return { paths, fallback: false };
};

export const getStaticProps: GetStaticProps<Props> = async ({ params }) => {
  const product = await getProduct({ slug: params.slug });

  return {
    props: { product },
    revalidate: 3600, // ISR: cache for 1 hour
  };
};

Here, getStaticPaths creates all product routes at build time, and getStaticProps returns the product data for each route. The data is cached, and the page regenerates only after the revalidate interval has passed. This means users will not trigger a Supabase query every time they visit a statically generated page, as long as the cached version is still valid. Great for performance, but it requires pre-building all routes.

App Router: Flexibility and Dynamism

Now, let’s look at the App Router. It starts similarly by using generateStaticParams to generate static routes:

export const revalidate = 3600;

export async function generateStaticParams() {
  const { data: products } = await supabase
    .from("products")
    .select("slug");

  return products.map(({ slug }) => ({
    slug
  }));
}

However, here's where things get interesting: In the App Router, server components are rendered on every request, even if the page has been statically generated.

// app/products/[slug]/page.tsx
export default async function ProductPage({ params }) {
  const product = await getProduct({ slug: params.slug });

  return <div>{product.name}</div>;
}

Every time a user visits a product page, the server component fetches the product data, and the Supabase query is triggered again, even if the page was previously statically generated. This is a major difference from the Pages Router.

Why does this happen?

generateStaticParams: This only generates static routes but does not cache the data for server components.
Server components: They are rendered server-side on each request. If ISR is enabled (via the revalidate option), it applies to the page itself, not the queries inside the server component.

How does this impact performance?

The App Router adds greater flexibility for developers, allowing dynamic route generation without the need to cache data upfront. However, unlike the Pages Router, ISR in the App Router primarily governs the rendering process, not the caching of database or API requests. This makes the approach more dynamic but may require extra optimization for repeated database queries.

In short, while Pages Router excels at static generation and caching, App Router leans towards more dynamic, real-time data fetching, which offers greater flexibility but can also introduce more overhead if not carefully optimized.

Caching Requests in the App Router: Why and How?

So, now you know how data handling in the App Router differs from the Pages Router. But what if you need to cache requests and control how often they're executed? Unlike Pages Router, where data could be cached during build time, App Router gives you more flexibility—which means we need to approach caching differently.

Let’s explore two popular ways to cache requests in the App Router.

1. Using the Next.js `fetch` API

Next.js offers built-in support for caching through its fetch API. By default, it caches data, but you can configure it with more precision. For example, to cache data for one hour, you can use the next: { revalidate: 3600 } option:

export async function getProduct({ slug }) {
  const response = await fetch(`https://api/products/${slug}`, {
    next: { revalidate: 3600 }, // Cache the data for one hour
  });

  return response.json();
}

It's simple: whenever a user requests the product page, Next.js checks if the revalidate time has passed. If it has, the request is made again; if not, the cached response is used. This is handy when you need data to refresh periodically but not on every single request.

2. The Experimental Approach: `unstable_cache`

If you need more granular control over caching, Next.js provides an experimental feature called unstable_cache. This allows you to explicitly cache certain requests and even assign tags for cache invalidation.

Here’s an example of caching product data using unstable_cache:

export default async function ProductPage({
  params: { slug },
}: {
  params: ProductPageParams;
}) {
  const getProductCached = unstable_cache(
    () => getProduct({ slug }),
    [slug],
    {
      tags: ["products"],
      revalidate: 3600,
    }
  );

  const product = await getProductCached();

  if (!product) {
    notFound();
  }

  return (
    <div className="py-4">
      <ProductDetails product={product} />
    </div>
  );
}

What’s happening here? The unstable_cache function caches the result of the request based on key parameters (in this case, slug). You can also set caching tags (like ["products"]), which gives you more flexibility when managing cache invalidation. The revalidate option controls how long the data stays cached.

Cache Control = Performance Control

Caching is a key part of performance optimization. It helps you avoid unnecessary API or database requests while ensuring that users get fresh data. With Next.js, you have full control over how and when data should refresh—whether you go with the built-in fetch caching or opt for the more flexible unstable_cache.

Now, you can manage caching in your App Router-powered app like a pro, saving resources and speeding up responses for your users!

Now that we’ve covered how the App Router structures pages and enhances navigation with components like layout.tsx and loading.tsx, it’s time to dive into more advanced routing features. Two of the key functions here are parallel routes and intercepting routes.

Parallel routes allow you to load and render multiple parts of the interface simultaneously, boosting performance and enabling more dynamic content handling. Intercepting routes take things even further, offering flexibility to control how content is displayed—like showing modal windows on top of an existing page.

In the next section, we’ll explore how parallel and intercepting routes work together to help you create intuitive, responsive interfaces with smooth navigation.

Dive into Next.js Server Actions: Simplifying Data Fetching & Mutations

Nikita Bogachenkov — Wed, 09 Oct 2024 12:00:00 +0000

In previous sections, we dove into SSR and Server Components. Now, let’s explore another powerful tool in Next.js — Server Actions.

Server Actions introduce a completely new way of handling data. Instead of making traditional API calls from the client to the server and then updating the client-side state, you can now call server-side functions directly from your components. This eliminates many unnecessary steps, reduces network requests, and improves performance.

How to Create a Server Action

Server Actions are defined using the "use server" directive. There are two primary ways to define them:

Inside a function. A simple and convenient approach is to place a Server Action directly within server components:

// @/components/Catalog.tsx
export default function Catalog() {
  async function deleteProduct() {
    "use server"
    // ...
  }
  return (
    // ...
  )
}

In a separate file. This approach allows Server Actions to be used inside both client and server components:

// @/app/actions/loadProducts.tsx
"use server"

export async function deleteProduct() {}

Using Server Actions for Mutations

Let’s say you need to delete a product from the catalog. Traditionally, you would send a DELETE request via an API, process the response, and update the interface:

import type { NextApiRequest, NextApiResponse } from 'next'
import { createClient } from "@/utils/supabase";

type ResponseData = {
  products: Product[];
}

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse<ResponseData>
) {
  const requestMethod = req.method;
  switch (requestMethod) {
    case "GET":
      // ...
    case "DELETE":
      const { product_id } = req.body;
      await supabase
        .from("products")
        .delete()
        .eq("id", product_id);
      res.status(200).json({ message: "Success" });
      break;
    default:
      res.setHeader('Allow', ['GET', 'POST', 'DELETE']);
      res.status(405).end(`Method ${req.method} Not Allowed`);
  }
}

export default function Catalog() {
  const { data: products, mutate } = useSWR('/api/catalog', fetcher);

  const handleDelete = async (product_id: string) => {
    try {
      const response = await fetch(
        '/api/catalog',
        {
          method: 'DELETE',
          headers: {
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({ product_id }),
        }
      );
      if (response.ok) {
        // revalidate cache
        mutate();
      } else {
        // show error message
      }
    } catch (err) {
      // do something with error
    }
  }

  return (
    <ProductList>
      {products.map(p => (
        <ProductCard key={p.id} onDelete={() => handleDelete(p.id)} />
      ))}
    </ProductList>
  )
}

With Server Actions, it’s much simpler:

// @/app/actions/deleteProduct.tsx
"use server";
import { createClient } from "@/utils/supabase";

export const deleteProduct = async (product_id: string) => {
  const supabase = createClient();
  await supabase
        .from("products")
        .delete()
        .eq("id", product_id);
  // Revalidating the Next.js Cache
  revalidatePath('/catalog');
}

And here’s what the component would look like:

import getAllProducts from "app/actions/getAllProducts";
import deleteProduct from "app/actions/deleteProduct";

export default async function Catalog() {
  const products = await getAllProducts();

  return (
    <ProductList>
      {products.map(p => (
        <ProductCard key={p.id} onDelete={() => deleteProduct(p.id)} />
      ))}
    </ProductList>
  )
}

Now, there’s no need to worry about making client-side requests—everything happens server-side.

Cache Management: `revalidatePath` and `revalidateTag`

After performing a mutation, you need to update the cache so that the changes are reflected in the UI. Next.js provides two functions for this:

revalidatePath—refreshes the cache for a specific path. For example, if a product is deleted, you would need to revalidate the /catalog page to display up-to-date data.
revalidateTag—refreshes a specific piece of data (rather than the whole page) using a tag:

// @/components/Catalog.tsx
// We fetch catalog data with a fetch request and assign a tag
export default async function Catalog() {
  const { data: products } = await fetch(
    "https://someproject.supabase.co/rest/v1/products?select=*",
    {
      next: {
        tags: ["catalog"]
      }
    }
  )
  return (
    // ...
  )
}

// Then we can revalidate our request within a Server Action
"use server";
import { createClient } from "@/utils/supabase/server";
import { revalidateTag } from "next/cache";

export const deleteProduct = async (product_id: string) => {
  await supabase
    .from("products")
    .delete()
    .eq("id", product_id);
  revalidateTag('catalog');
}

Fetching Data with Server Actions

While Server Actions are often introduced as tools for data mutations, they can also be used to fetch data directly from the server. Here’s an example:

// app/actions/loadProducts.tsx
"use server"
export async function loadProducts() {
  // Fetch data from server or DB
}

Then use it in a component:

// components/Catalog.tsx
import { loadProducts } from '@/actions/loadProducts.tsx';

export default async function Catalog() {
  const products = await loadProducts();
  return (
    // Render the product catalog
  )
}

Finally, we add the component to the catalog page using Suspense to handle the loading state:

// app/catalog/page.tsx
import { Suspense } from "react";
import Catalog from "@/components/Catalog";

export default async function CatalogPage() {
  return (
    <Suspense fallback={<CatalogSkeleton />}>
      <Catalog />
    </Suspense>
  )
}

At first glance, this may seem like a powerful way to handle data, but there are two important things to keep in mind:

1. Server Actions are executed sequentially

This is one of the biggest limitations: each Server Action is executed strictly one after another. This means that if you are making several server requests (e.g., fetching products, categories, and recommendations), they cannot happen in parallel. Unlike the standard fetch where you can perform multiple parallel requests and await their completion simultaneously, here the sequential execution may slow down the response time. In performance-critical scenarios, this could become an issue.

2. Server Action requests are always POST requests

Another key point is that all Server Action requests, regardless of their purpose, use the POST method. While this may not be critical in most cases, traditional API routes in Next.js offer more flexibility—they can accept GET requests, enabling caching and more efficient load distribution.

Ultimately, the choice is yours. Server Actions simplify the architecture of your app, eliminating the need for API routes for both mutations and even data fetching. But if you require parallel data loading or cacheable GET requests, traditional API routes might still be more suitable.

Using Server Actions with Forms

Server Actions can significantly simplify form handling in React by allowing HTML forms to directly connect to server-side logic. In Next.js, this is implemented by passing a Server Action as the form’s action. Once the form is submitted, the server function receives the FormData object and can process it like any other server-side operation. Here’s an example:

// app/actions/createProduct.tsx
"use server";

export default async function createProduct(formData: FormData) {
  const { data, error } = await supabase
    .from('products')
    .insert({
      title: formData.get("title"),
      description: formData.get("description"),
      price: +formData.get("price"),
      category_id: +formData.get("category_id")
    });

  redirect(`/dashboard/products/${data.id}`);
}

In this example, createProduct takes the form data, saves the new product in the database, and then redirects the user to the newly created product’s page. Now let’s see how this Server Action integrates with a form:

// app/components/forms/CreateProduct.tsx
"use client";
import createProduct from '@/actions/createProduct';
import { useFormStatus } from "react-dom";

export default function CreateProductForm() {
  const { pending } = useFormStatus();

  return (
    <form action={createProduct}>
      // ...
      <Button isLoading={pending}>
        Create product
      </Button>
    </form>
  )
}

As you can see, the Server Action is simply passed into the form’s action attribute. When the form is submitted, it asynchronously runs the server function createProduct. However, there are a few key things to note:

Asynchronous handling with useFormStatus

React added support for tracking form status through the useFormStatus hook. This hook returns an object containing a pending field, which indicates whether the form submission is in progress. This is useful for showing loading indicators and preventing duplicate submissions while the form is being processed.

POST Requests and Redirects

Just like with data fetching, forms using Server Actions are always submitted via POST. This means you can’t cache these requests, but for most form operations (like creating or updating data), caching isn’t necessary anyway. Plus, Server Actions unlock the ability to perform server-side redirects, as seen in our example with the redirect function.

Adding Server Actions to forms makes handling them incredibly simple and elegant, reducing the amount of client-side code and improving your app’s architecture. However, it’s crucial to remember that these requests are always processed sequentially and must use the POST method. You’ll need to weigh this when deciding between Server Actions and more traditional API routes.

Server Actions significantly streamline how you handle data, eliminating the need for client-side API calls and letting you perform server-side operations directly from your components. This reduces app complexity and lightens the client’s load, ultimately leading to a faster and more responsive user experience.

But how does this tool fit into the larger Next.js architecture, and how does it interact with its other powerful features? To answer that, we need to dive into the App Router. In the next section, we’ll explore how the App Router helps you create more flexible routes, simplifies page management, and boosts performance with technologies like parallel rendering and nested layouts.

Dive into Next.js Server Components: Unlocking Performance & Scalability

Nikita Bogachenkov — Tue, 08 Oct 2024 12:00:00 +0000

We’ve already explored how SSR and ISR can significantly offload the client by moving heavy data processing to the server. But rendering in React continues to evolve—and a powerful new tool, server components, is coming to the forefront.

Server components represent a true evolution in rendering. They allow for flexible separation of logic between the client and the server. Previously, we had to carefully consider where and how rendering happens, but server components remove that headache. Now, complex calculations and database queries can be performed on the server, with the client only receiving what’s necessary.

In practice, this means less client-side code (a smaller bundle size), faster page load times, and more control over rendering. Let’s dive into how this works.

The Power of Server Components

As the name implies, server components run exclusively on the server. They don’t hold state or interactivity but can execute database queries directly:

import React from "react";

import ProductsGrid from "@/components/ui/ProductsGrid";
import EmptyScreen from "@/components/ui/EmptyScreen";
import { getProducts } from "@/app/actions/getProducts";
import { SearchParams } from "@/app/(home)/page";

interface ICatalogProps {
  children?: React.ReactNode;
  searchParams: SearchParams;
}

const Catalog: React.FC<ICatalogProps> = async ({ searchParams }) => {
  const products = await getProducts({
    category_id: searchParams.category_id as string,
    min_price: searchParams.min_price as string,
    max_price: searchParams.max_price as string,
  });

  if (!products) return <EmptyScreen />;

  return <ProductsGrid items={products} />;
};

export default Catalog;

What sets server components apart from client components? First, they can be asynchronous, allowing side effects like API or database requests to be made during rendering. In client components, you’d use useEffect for this, but server components render only once on the server and don’t re-render on the client.

This means server components don’t have state or hooks like useState or useEffect, as they don’t re-execute on the client side after the initial render.

Server components are ideal for rendering data that doesn’t require frequent updates or interactivity. However, for more dynamic tasks, a hybrid approach—combining server and client components—works best.

How Server Components Work in Next.js

If server components only render on the server, aren’t included in the bundle, and can contain client components, how does React understand how to render the entire UI?

Let’s imagine we have a ProductInfo component:

import React from "react";
import CartButton from "../CartButton";

interface IProductInfoProps {
  children?: React.ReactNode;
}

const ProductInfo: React.FC<IProductInfoProps> = (props) => {
  return (
    <header id="container">
      <h1 id="product-title">Banana</h1>
      <p id="product-price">$1.00</p>
      <CartButton id="cart-button" />
    </header>
  );
};

export default ProductInfo;

Where CardButton is a client component:

'use client'
import React, { ComponentProps, useState } from 'react';

interface ICartButtonProps extends ComponentProps<"button"> {
  children?: React.ReactNode;
}

const CartButton: React.FC<ICartButtonProps> = (props) => {
  const [added, setIsAdded] = useState(false);
  const toggle = () => setIsAdded(v => !v);
  return (
    <button onClick={toggle}>
      {added ? "Remove from" : "Add to"} cart
    </button>
  );
}

export default CartButton;

So, how does the rendering happen in this case? Let’s break it down.

On the server side:

React transforms the server component into a React Server Component Payload (RSC Payload)—a compact data representation used to update the DOM on the client. This payload contains the render results, placeholders for client components, and links to the corresponding JavaScript files.
Next.js uses this payload to generate HTML on the server.

If you inspect the result, you’ll see a <script> tag containing something like self.__next_f.push(…) with JSON data inside. When unpacked, you can see the rendered ProductInfo along with a placeholder and a link to the client component CartButton:

7: {
  name: "ProductInfo",
  env: "Server"
},
7: [
  "$","header",null,
  {
    "id":"container",
    "children": [
      ["$", "h1", null, { "id":"product-title", "children":"Banana"}],
      ["$", "p", null, { "id":"product-price", "children":"$$1.00"}],
      ["$", "$L8", null, { "id":"cart-button" }]]
  }
]
8: ["(app-pages-browser)/./app/components/CartButton/CartButton.tsx"]

On the client side:

The HTML immediately displays a non-interactive version of the interface on the first page load.
React uses the RSC Payload to reconcile the trees of server and client components, updating the DOM.
JavaScript instructions are then used to hydrate client components, turning the UI interactive.

This separation of logic between the client and the server helps maintain high performance and reduces the amount of data transferred.

Anything Imported in a Client Component Becomes Client-Side

When you add the "use client" directive to a component, remember one key rule: anything you import into that component automatically becomes client-side. Even if a component was meant to be a server component, it will now execute on the client, which can lead to unexpected outcomes.

Let’s imagine we have a product page that needs to store state—whether an item is added to the cart:

"use client"
import ProductDetails from "@components/ProductDetails";
import ProductPrice from "@components/ProductPrice";
import Button from "@components/Button";

export default ProductPage = () => {
  const [isInCart, toggleIsInCart] = useCartState();
  return (
    <>
      <ProductDetails />
      <ProductPrice />
      <Button onClick={toggleIsInCart}>
        {isInCart ? "Remove from" : "Add to"} cart
      </Button>
    </>
  );
}

In this example, the "use client" directive applied to ProductPage automatically turns all imported components—ProductInfo, ProductPrice, and Button—into client components. Even if they were initially server components, they now render on the client.

But what if you want to keep these components server-side to avoid unnecessary client-side load? The solution is simple—separate the client logic and move it into isolated components:

"use client"

export default AddToCartWrapper = ({ children }) => {
  const [isInCart, toggleIsInCart] = useCartState();
  return (
    <>
      {children}
      <Button onClick={toggleIsInCart}>
        {isInCart ? "Remove from" : "Add to"} cart
      </Button>
    </>
  );
}

Now you can remove the "use client" directive from the main ProductPage component and keep the server components server-side:

import ProductDetails from "@components/ProductDetails";
import ProductPrice from "@components/ProductPrice";
import AddToCartWrapper from "@wrappers/AddToCartWrapper";

export default ProductPage = () => {
  return (
    <AddToCartWrapper>
      <ProductDetails />
      <ProductPrice />
    </AddToCartWrapper>
  );
}

Now, ProductInfo and ProductPrice are rendered on the server, while the client-side logic is isolated in the AddToCartWrapper component.

It’s important to shift your mindset when working with server components—it can be confusing at first, but once you get the hang of it, you’ll unlock a powerful optimization tool.

At this point, we’ve taken a deep dive into server-side rendering and server components in Next.js. These techniques not only improve SEO but also create a smoother, more responsive user experience.

In the next part, we’ll explore Server Actions—a new way of handling server logic in Next.js. You’ll learn how they allow you to perform server-side actions directly from components, reducing code duplication and improving your application’s performance.

Dive into Next.js Server-Side Rendering (SSR): From SPA to ISR

Nikita Bogachenkov — Mon, 07 Oct 2024 14:00:00 +0000

Server-side rendering (SSR) and server components are not just buzzwords in modern web development—they’re key tools that can improve both SEO and user experience while making your app more efficient. In this first part of our series, we’ll explore how to properly set up SSR and dive into how server components can boost performance and simplify your app's architecture. We’ll break down the details to help you get the most out of these technologies and build an application that is fast, reliable, and user-friendly.

Performance Optimization: Speeding Things Up and Keeping Users Happy

Performance optimization isn't just a trendy phrase developers toss around—it’s critical for creating an exceptional user experience. A fast website is like a high-performance sports car: it’s not only impressive, but it also keeps users engaged and coming back for more.

When pages load instantly, and the interface feels smooth, users stick around. They’re less likely to close the tab out of frustration. A slow website? That’s like watching paint dry—no one wants to do that. The longer they wait, the more likely they are to leave and never return. This not only hurts user engagement but also your SEO, since search engines tend to favor faster sites.

But the benefits don’t stop there! Optimizing performance also reduces the load on your servers and cuts down on bandwidth consumption. This is particularly important for users with slower internet connections or older devices—they won't have to suffer through endless loading screens. Ultimately, performance optimization makes your site more accessible and enjoyable for everyone.

SSR: How Server-Side Rendering Changes the Game

When it comes to web application performance, understanding how rendering impacts the user experience is crucial. In the early days of React, most applications were built as single-page apps (SPA), relying heavily on client-side rendering. This approach had its merits, but it quickly became apparent that it wasn’t ideal for every scenario.

Enter Server-Side Rendering (SSR), the true game-changer for optimizing load times and interactivity. SSR allows pages to be rendered on the server and delivered to the user already fully composed, completely shifting the user experience.

But SSR is just one part of a bigger picture. As it evolved, new concepts emerged, like Static Site Generation (SSG) and Incremental Static Regeneration (ISR). These approaches open even more doors for optimization, making your applications faster and more responsive.

In the next section, we'll dive into the specifics of SSR, explore how it revolutionized React application development, and examine its benefits. Then, we’ll move on to server components and their role in this fascinating process.

The Evolution of React Applications: From SPA to SSR

When we first started using React, most applications were single-page apps (SPAs) relying on client-side rendering. The process looked straightforward: we had a single HTML file with a root div and a script that loaded our bundle:

<html>
  <head>
    <!-- Styles, meta tags, external scripts, etc. -->
  </head>
  <body>
    <div id="root"></div>
    <script src="/dir/bundle.js"></script>
  </body>
</html>

Once the bundle was loaded, React took over, rendering the DOM for the application and inserting it into the div. However, until this process was complete, users would see nothing but a blank screen, delaying the First Contentful Paint (FCP) — the moment the first visible element appeared on the screen.

But this was just the beginning of the wait. Even after the interface was displayed, the app still had to become interactive. This process took additional time, and only after React added event handling did Time to Interactive (TTI) occur.

As apps grew in size, these delays worsened. But even that wasn’t the end of the waiting.

Finally, users often encountered loaders or skeletons while waiting for data to arrive from an API. The Largest Contentful Paint (LCP) — the moment when the actual content replaced the skeletons — signaled the end of this loading process.

Enter Server-Side Rendering (SSR)! With SSR, the page is rendered on the server and sent to the user fully assembled. The bundle script is still necessary, but this approach offers two significant advantages:

A fully-rendered page for the user: Instead of seeing a blank screen as they would with client-side rendering, users receive a fully rendered page with content right away, dramatically speeding up FCP.
Client-side hydration: React no longer creates the entire DOM from scratch; instead, it works with the existing content, adding interactivity through a process called hydration. This reduces the TTI because the browser only needs to add dynamic elements, rather than build the entire interface from scratch.

Moreover, SSR sped up the display of final content. Unlike client-side rendering, where LCP could be delayed until data was fetched from an API, server-side rendering allowed for ready-to-display content. This not only sped up the loading process but also made the entire interaction smoother and more responsive for the user.

By leveraging SSR, we were able to make React applications faster and more enjoyable for users, leading to better user retention and an improved overall experience.

The Evolution of SSR: SSG and ISR

Server-Side Rendering was just the beginning, but over the years, new methods have emerged to make static site generation even more powerful and flexible. Let’s explore Static Site Generation (SSG) and Incremental Static Regeneration (ISR) — two techniques that have pushed performance to the next level.

1. Static Site Generation (SSG) — Build-Time Rendering

Imagine this: instead of generating pages on every request (as SSR does), pages are generated once — at build time. This is Static Site Generation. The user gets a pre-built HTML page almost instantly because it's already prepared, significantly reducing server load and speeding up the page load.

The beauty of it? Even though the page is static, it retains all the interactivity thanks to React’s hydration — when JavaScript "brings to life" the pre-rendered page and adds dynamic behavior.

In Next.js, if you’re not using getServerSideProps or getInitialProps, pages are generated using SSG by default. This makes your site incredibly fast by relying on static content.

2. Incremental Static Regeneration (ISR) — Dynamic Generation on Request

ISR takes SSG to the next level. What if your pages could update dynamically, but without rebuilding the entire site? That’s what ISR does. You can update pre-generated pages at specific intervals or even on demand, without wasting resources on regenerating everything.

Let’s say you have an e-commerce store with hundreds of products. Instead of rebuilding the entire catalog every time something changes, ISR allows you to regenerate only the pages that have been requested and have outdated cache. Here’s an example of using revalidate for a product page:

interface Props {
  product: Product;
}

export const getStaticProps: GetStaticProps<Props> = async ({ params }) => {
  const response = await fetch(`https://api.store.app/product/${params.id}`);
  const product = await response.json();

  return {
    props: { product },
    // Cache lifetime for the page in seconds
    // Next.js will automatically set cache-control headers
    revalidate: 600, 
  };
};

Now, the product pages stay cached for the specified duration. But if someone requests a page after that time (in our example, 10 minutes), Next.js will regenerate the page. After that, the new version will remain in the cache for the next set period. Additionally, if a new product is added, Next.js will generate the page "on-the-fly" during the first request and cache it for the same duration.

SSR and Its Optimization Horizons

SSR became a great solution for improving load times and initial rendering in React, while evolutionary methods like Static Site Generation (SSG) and Incremental Static Regeneration (ISR) have given us more control and flexibility in building optimal, fast, and scalable applications.

With these methods, we can now offer users pre-built pages with minimal delay, dynamically update them when necessary, and most importantly, reduce server load.

But the evolution doesn’t stop here. In the React world, another powerful tool is emerging — server components. These components take server-side rendering to a new level, changing how we divide logic between client and server. In the next part, we’ll dive into how server components work and why they’re crucial for further optimizing performance.

Memoization in React: When It Helps and When It Hurts

Nikita Bogachenkov — Thu, 19 Sep 2024 18:04:04 +0000

When asked, “Why is React so fast?” you often hear, “Because of the Virtual DOM.” But what does that really mean? How does rendering and re-rendering work in React? And when should you actually use memo, useMemo, and useCallback?

Let’s explore these concepts in today’s article.

Virtual DOM and the rendering process

Operations involving the real DOM are considered slow because every time the browser updates the DOM, it needs to repaint the page, recalculate styles, perform layout computations, and handle other resource-heavy tasks.

Virtual DOM allows React to significantly reduce the number of these operations. All changes first happen in memory, and only the minimal necessary updates are pushed to the real DOM.

The process of how the Virtual DOM works can be broken down into several steps:

Creating the Virtual Tree (VDOM)
When a React component is rendered, a tree of elements is created — a virtual representation of the UI. This tree is a set of JavaScript objects that mimic the structure of the real DOM but are faster to process.

For example, the following code:

<div className="container">
  <img
    src="https://placehold.co/600x400"
    alt="placeholder"
    width={600}
    height={400}
  />
  <h1 className="title">Here we go!</h1>
</div>

Turns into this object:

{
  type: "div",
  props: {
    className: "container",
    children: [
      {
        type: "img",
        props: {
          alt: "placeholder",
          height: 400,
          src: "https://placehold.co/600x400",
          width: 600,
        },
      },
      {
        type: "h1",
        props: {
          className: "title",
          children: 'Here we go!'
        }
      }
    ],
  },
}

Updating the Virtual DOM (Render phase)
When a component’s state changes, React creates a new virtual tree. However, at this stage, no changes are made to the real DOM. React only updates the Virtual DOM.
Comparing the old and new Virtual DOM (Reconciliation)
To minimize updates to the real DOM, React uses a reconciliation process that compares the old and new virtual trees to compute which elements have changed. This process is known as “diffing.”

The algorithm is based on two key rules:
Recursive comparison: React starts comparison from the root node and moves downwards.
Comparison by node type: If the node type hasn’t changed, React updates its properties. If the type has changed, the entire subtree is replaced.
Updating the real DOM (Commit phase)
After React determines which parts of the tree have changed, it updates only the modified nodes in the real DOM. This makes the process fast since React minimizes interactions with the real DOM, which are typically time-consuming.

Thus, the Virtual DOM is the key component that makes React so fast. It avoids full interface re-rendering by updating only the parts that have changed.

Re-rendering and how to avoid it

According to the React documentation, a component re-renders in two cases:

It’s being rendered for the first time.
The component’s state or one of its ancestors’ state has changed (including changes in hooks and context).

This is evident in the following example (the Card component blinks on every re-render). Although the second Card has no connection to the counter state, the App component re-renders, causing both Card components to update.

function App() {
  const [count, setCount] = useState(0);
  const increment = () => setCount((c) => c + 1);

  return (
    <Container>
      <Card onClick={increment}>Counter: {count}</Card>
      <Card>I have no state</Card>
    </Container>
  );
}

How to avoid unnecessary re-renders?

At first glance, the solution seems to be memoization. However, it’s important to remember that the cost of memoization can outweigh its benefits, as it requires resources for caching and additional computations. Using useMemo and useCallback for everything is an example of premature optimization. React is already highly optimized, so if your application is running smoothly, avoid adding memoization without reason. First, identify performance bottlenecks.

When memoization is unnecessary?

When decomposition is possible
For example, you can move the counter logic into a separate component:

import React, { useCallback, useState } from "react";

interface ICounterProps {
  children: (count: number, increment: VoidFunction) => React.ReactNode;
}

const Counter: React.FC<ICounterProps> = ({ children }) => {
  const [count, setCount] = useState(0);
  const increment = useCallback(() => setCount((c) => c + 1), []);

  return children(count, increment);
};

export default Counter;

So the App component looks like this:

import Card from "./Card";
import Counter from "./Counter";

function App() {
  return (
    <>
      <Counter>
        {(count, increment) => (
          <Card onClick={increment}>Counter: {count}</Card>
        )}
      </Counter>
      <Card>I have no state</Card>
    </>
  );
}

export default App;

Now, the second Card component will no longer re-render when the state changes.

When the component is simple and does not contain complex computations
For example, if your component only displays text, memoization may be unnecessary.

When memoization is used in the wrong way
Let’s return to our example. Imagine you have a list of fruits passed to the Card component. (While it would be logical to move this list outside of the App component, let’s assume we get it directly from an API):

import { useCallback, useState } from "react";
import Card from "./Card";

function App() {
  const [count, setCount] = useState(0);
  const increment = useCallback(() => setCount((c) => c + 1), []);
  const fruits = ["Apple", "Orange", "Guava", "Mango", "Banana"];
  return (
    <>
      <Card onClick={increment}>Counter: {count}</Card>
      <Card>
        {fruits.join(", ")}
      </Card>
    </>
  );
}

export default App;

When you pass objects, arrays, or functions (so-called non-primitive values) as props, they are recreated every time the parent component renders. This causes the child component to consider these props as changed and re-render.

So, if you simply wrap the component in React.memo, it won’t solve the problem:

export default memo(Card);

import { useCallback, useState } from "react";
import Card from "./Card";

function App() {
  const [count, setCount] = useState(0);
  const increment = useCallback(() => setCount((c) => c + 1), []);
  const fruits = ["Apple", "Orange", "Guava", "Mango", "Banana"];
  return (
    <>
      <Card onClick={increment}>Counter: {count}</Card>
      <Card items={fruits} />
    </>
  );
}

export default App;

A correct approach is also to memoize the fruits array using useMemo:

const fruits = useMemo(() => {
  return ["Apple", "Orange", "Guava", "Mango", "Banana"]
}, []);

It’s also important to remember the reverse situation: if the props are memoized but the component itself is not wrapped in memo, it will still re-render when the parent component updates.

When memoization is useful:

When the component performs complex or resource-intensive calculations that don’t need to be repeated with every render.

When using hooks:

import { useMemo } from "react";

export const useFruits = () => {
  return useMemo(
    () => ["Apple", "Orange", "Guava", "Mango", "Banana"],
    []
  );
};

When using Context:

import {
  createContext,
  ReactNode,
  useMemo,
  useContext,
  useState,
} from "react";

type FruitsState = {
  fruits: string[];
};

type FruitsAPI = {
  setFruits: (fruits: string[]) => void;
}

const FruitsContext = createContext<FruitsState>({} as FruitsState);
const FruitsAPIContext = createContext<FruitsAPI>({} as FruitsAPI);

export const FruitsProvider = ({ children }: { children: ReactNode }) => {
  const [fruits, setFruits] = useState<FruitsState["fruits"]>([
    "Apple",
    "Orange",
    "Guava",
    "Mango",
    "Banana",
  ]);

  const state = useMemo(() => ({
    fruits,
  }), [fruits]);

  const api = useMemo(() => ({
    setFruits
  }), [])

  return (
    <FruitsAPIContext.Provider value={api}>
      <FruitsContext.Provider value={state}>
        {children}
      </FruitsContext.Provider>
    </FruitsAPIContext.Provider>
  );
};

export const useFruitsAPI = () => useContext(FruitsAPIContext);
export const useFruits = () => useContext(FruitsContext);

Note: If your state consists of multiple parts used in different components, this can cause unnecessary re-renders.
For example, we have the following structure:

const state = useMemo(() => ({
  fruits,
  favoriteFruit,
  caribbeanFruits
  // and so on
}), [fruits, favoriteFruit, caribbeanFruit])

const FruitsList = () => {
  const { fruits } = useFruits();
  // ...
}
const FavoriteFruit = () => {
  const { favoriteFruit } = useFruits();
  // ...
}
const СaribbeanFruitsList = () => {
  const { caribbeanFruits } = useFruits();
  // ...
}

If one part of the state (like favoriteFruit) changes, all components using other parts of the state (like fruits or caribbeanFruits) will also re-render.

To avoid this, you can the large provider into multiple providers:

 <FruitsContext.Provider value={fruits}>
  <FavoriteFruitContext.Provider value={favoriteFruit}>
    <CaribbeanFruitsContext.Provider value={caribbeanFruits}>
      {children}
    </CaribbeanFruitsContext.Provider>
  </FavoriteFruitContext.Provider>
</FruitsContext.Provider>

Now, only the consumers of the updated part of the state will re-render. By splitting the context into smaller, isolated parts, you can significantly reduce unnecessary re-renders and enhance overall performance.

React indeed provides high performance due to the Virtual DOM and its optimized rendering system. However, memoization is not always the solution to all problems. Before using memo, useMemo, or useCallback, ensure that it’s really necessary in your case. Thoughtful use of these tools can help avoid unnecessary re-renders and maintain high performance.

Building Micro Frontends with Vite, React, and TypeScript: A Step-by-Step Guide

Nikita Bogachenkov — Tue, 17 Sep 2024 09:51:18 +0000

In the world of modern web development, the demand for scalable and maintainable applications continues to grow. One way to meet these demands is by breaking down large applications into smaller, independent units through the use of micro frontends. By doing so, we can achieve greater flexibility in development and deployment. This also allows teams to work in parallel on different parts of the application, which speeds up the development process.

In this article, we'll explore how to build a micro frontend application using Vite, React, and TypeScript, leveraging Module Federation—a powerful feature that simplifies the creation and integration of micro frontends. Additionally, we'll dive into how to organize the sharing of TypeScript types and application state between different micro frontend applications.

What are Micro Frontends and Module Federation?
About the Application
Types Sharing
Remote Application 1 - UI Components
Remote Application 2 - Artist Details
Host Application - Artist List
State Sharing in Micro Frontends
Conclusion

What are Micro Frontends and Module Federation?

Before diving into the details, let's clarify some key terms — Micro Frontends and Module Federation.

A Micro Frontend is a development approach where an application is split into small, independent modules, each of which can be developed and deployed separately. This allows teams to work on different parts of the application in parallel, speeding up the development process.

In a typical micro frontend architecture, there is a host application that integrates and utilizes data from one or more remote applications. These remote applications can interact both with the host and with each other.

Module Federation is a feature of Webpack 5 that allows modules from other applications to be dynamically loaded at runtime. This simplifies the creation of micro frontends, as it enables applications to share code without having to rebuild the entire project.

About the Application

Source code

The application is a list of artists fetched from the Last.fm API. When an artist is selected, a window opens with detailed information about them.

The application's structure will be as follows:

Host application: displays a list of artists.
Remote application 1: shows artist details.
Remote application 2: contains UI components.

I won’t go into detail about creating React components, but I will provide links to the source code for each section.

Types Sharing

Source Code

When working with micro frontends, code is dynamically loaded, but there’s no automatic way to retrieve TypeScript types. Since we are using TypeScript in this project and various parts of the application refer to the same types, these types need to be shared between modules.

There are several approaches to achieve this, but in this article, we will focus on creating an npm package for types.

Step 1: Creating an npm Package

Let’s start by creating a separate directory and installing the necessary dependencies:

mkdir types && cd types
yarn init -y
yarn add @types/react

In package.json, we’ll provide the basic information:

{
  "name": "vmf-app-types",
  "version": "1.0.0",
  "description": "Type declarations for the showcase project",
  "main": "index.js",
  "license": "MIT",
  "types": "index.d.ts",
  "registry": "https://registry.npmjs.org/",
  "dependencies": {
    "@types/react": "^18.3.5"
  }
}

Step 2: Adding Interfaces

Next, create the index.d.ts file where we will define the interfaces for the artists and albums that we will fetch from the Last.fm API:

type ImageSize = "small" | "medium" | "large" | "extralarge" | "mega";

type Images = {
  size: ImageSize;
  "#text": string;
}[]

interface Artist {
  name: string;
  image: Images;
  listeners: number;
  mbid: string;
  url: string;
}

interface MusicEntity {
  url: string;
  image: Images;
  name: string;
  playcount: number;
}

Step 3: Modules for React Components

Since we’ll be sharing React components between applications, we need to declare modules for them (otherwise, it will make your linter angry). Let’s do that now to avoid revisiting this later:

// Last.fm interfaces
...

// ArtistDetails app
declare module "artistDetails/ArtistDetails" {
  import React from "react";

  interface ArtistDetailsProps {
    mbid: string;
    imgUrl: string | null;
  }

  const ArtistDetails: React.FC<ArtistDetailsProps>;
  export default ArtistDetails;
}

// UI app
declare module "ui/components" {
  import React from "react";

  const Wave: React.FC;

  interface ITitleProps extends React.ComponentProps<"h2"> {
    children?: React.ReactNode;
    size?: "xl" | "lg" | "base";
  }

  const Title: React.FC<ITitleProps>;

  export { Wave, Title }
}

After that, publish our package to npm:

npm login
npm publish

Now, we can use this package in each application.

Note #1

For each application using this package, you need to add a reference to it in the vite-env.d.ts file:

/// <reference types="mf-app-types" />

Another approach is to publish your types under the @types organization on npm.

Note #2

In this case, we’ve published the package as public. If you need privacy, you can create a private npm package and publish it, for example, via GitHub Package Registry.

Now, we can proceed to building the application.

Remote Application #1 - UI Components

Source Code

Our UI will consist of two components: a loading indicator (Wave) and a title (Title).

First, let’s create the UI application:

yarn create vite ui --template react-ts
cd ui
yarn

Then, install the necessary dependencies:

yarn add clsx tailwind-merge
yarn add -D tailwindcss postcss autoprefixer @originjs/vite-plugin-federation

The components will be located in src/components and exported from index.tsx:

export { default as Title } from './Title';
export { default as Wave } from './Wave';

Now, configure Module Federation in vite.config.ts using vite-plugin-federation:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import ModuleFederationPlugin from "@originjs/vite-plugin-federation";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    react(),
    ModuleFederationPlugin({
      name: "ui",
      filename: "remoteEntry.js",
      exposes: {
        "./components": "./src/components"
      },
      shared: ["react", "react-dom"],
    }),
  ],
  build: {
    target: "esnext",
    minify: false,
    cssCodeSplit: false
  }
})

Let’s go over each property of the plugin:

name - The name of the remote application.
filename - The entry file for the remote application (default is remoteEntry.js). We will later reference this file to load the remote application.
exposes - A list of components we want to expose from this module. In this case, we’re specifying components/index.tsx, which, in turn, exports our Wave and Title components.
shared - The dependencies and libraries we want to share between our applications. For example, if two applications use the same library, it doesn’t make sense to load it multiple times in the browser. Instead, we can define these dependencies and share them across both applications.

You can also fine-tune module sharing by specifying the library version, path, and other parameters. More information can be found here.

I recommend being cautious with shared libraries because it can impact tree-shaking. For instance, if you share a large icon library just to use one icon, or a UI library for one component (like a button), this can significantly increase the bundle size, potentially by several megabytes.

After configuring module federation, we can build our UI application and run it on port 3002. Note that the port must be explicitly set, as we will later reference this port when linking to the application.

package.json:

"preview": "vite preview --port 3002 --strictPort"

yarn build
yarn preview

Now it’s time to create the next remote application — the artist details window.

Remote Application #2 - Artist Details

Source Code

This application will expose the ArtistDetails component. This component accepts the artist's id and a link to their photo as props, loads data about the artist from the API, and displays their information, including the top 10 albums and tracks.

Just like with the UI app, we’ll start by creating a new application using Vite:

yarn create vite artist-details --template react-ts

Then, install the dependencies:

yarn add axios swr
yarn add -D tailwindcss postcss autoprefixer @originjs/vite-plugin-federation

Let’s configure module federation right away:

vite.config.ts

ModuleFederationPlugin({
  name: "artistDetails",
  filename: "remoteEntry.js",
  exposes: {
    "./ArtistDetails": "./src/components/ArtistDetails"
  },
  remotes: {
    ui: "http://localhost:3002/assets/remoteEntry.js"
  },
  shared: ["react", "react-dom", "swr"],
}),

You’ll notice a new field here — remotes. In this field, we specify the link to our remote UI application (this is where port 3002 comes in handy).

Then, we can use the UI components as if they were from a normal library:

import { Title, Wave } from "ui/components";

Now, let’s add the ArtistDetails component:

import React from "react";
import Info from "@components/Info";
import TopList from "@components/TopList";

interface IArtistDetailsProps {
  mbid: string;
  imgUrl: string;
}

const ArtistDetails: React.FC<IArtistDetailsProps> = ({ mbid, imgUrl }) => {
  return (
    // render artist details
  );
};

export default ArtistDetails;

We will also build this application and run it on port 3001:

vite preview --port 3001 --strictPort

Now, it's time to bring everything together, for which we’ll need the host application.

Host Application - Artist List

Source Code

The creation of this application is no different from the previous ones: we still use the Vite CLI:

yarn create vite artist-details --template react-ts

Next, we install the dependencies, but this time we’ll add @nextui and framer-motion:

yarn add axios swr @nextui-org/react framer-motion
yarn add -D tailwindcss postcss autoprefixer @originjs/vite-plugin-federation

Configure Module Federation:

ModuleFederationPlugin({
  name: "artistList",
  remotes: {
    artistDetails: "http://localhost:3001/assets/remoteEntry.js",
    ui: "http://localhost:3002/assets/remoteEntry.js"
  },
  shared: ["react", "react-dom", "axios", "swr"]
})

As you can see, the shared field is no longer necessary here. We simply use our remote applications.

In this application, we will load a list of top artists from Last.fm and display it as cards. When clicking on a card, we save the selected artist's id and image URL:

const [selectedArtistMbid, setSelectedArtistMbid] = useState<string | null>(null);
const [selectedArtistImgUrl, setSelectedArtistImgUrl] = useState<string | null>(null);

Then, we open a modal with the ArtistDetails component, which we previously exposed from the remote artistDetails application:

import React, { useEffect, useState } from "react";
import useSWR from "swr";
import { Spacer } from "@nextui-org/react";
import { LayoutGroup, motion } from "framer-motion";

import { fetcher } from "@utils/fetcher";
import { filterByPhoto } from "@utils/filterByPhoto";

import ArtistCard from "@components/ArtistCard";
import ArtistsLayout from "@components/ArtistsLayout";
import Modal from "@components/Modal";

import { Wave, Title } from "ui/components";
import ArtistDetails from "artistDetails/ArtistDetails";

interface IArtistListProps {
  children?: React.ReactNode;
}

export interface ArtistsResponse {
  artists: {
    artist: Artist[];
  };
}

const ArtistList: React.FC<IArtistListProps> = () => {
  const [selectedArtistMbid, setSelectedArtistMbid] = useState<string | null>(
    null
  );
  const [selectedArtistImgUrl, setSelectedArtistImgUrl] = useState<
    string | null
  >(null);

  const close = () => setSelectedArtistMbid(null);

  const { data, isLoading } = useSWR<ArtistsResponse>(
    "/?method=chart.gettopartists&format=json&limit=11",
    fetcher
  );

  useEffect(() => {
    const closeOnEscapePressed = (e: KeyboardEvent) => {
      if (e.key === "Escape") {
        close();
      }
    };
    window.addEventListener("keydown", closeOnEscapePressed);
    return () => window.removeEventListener("keydown", closeOnEscapePressed);
  }, []);

  const onArtistPress = (mbid: string, imgUrl: string) => {
    setSelectedArtistMbid(mbid);
    setSelectedArtistImgUrl(imgUrl);
  };

  if (isLoading) return <Wave />;

  if (!data) return <Title>Sorry, no data found</Title>;

  return (
    <LayoutGroup>
      <Title className="mx-auto" size="xl">
        Last.fm Top Artists
      </Title>
      <Spacer y={6} />
      <ArtistsLayout>
        {data.artists.artist.filter(filterByPhoto).map((a) => (
          <motion.div key={a.mbid} layoutId={a.mbid}>
            <ArtistCard artist={a} onPress={onArtistPress} />
          </motion.div>
        ))}
      </ArtistsLayout>
      {selectedArtistMbid && (
        <Modal layoutId={selectedArtistMbid} onClose={close}>
          <ArtistDetails
            mbid={selectedArtistMbid}
            imgUrl={selectedArtistImgUrl}
          />
        </Modal>
      )}
    </LayoutGroup>
  );
};

export default ArtistList;

Now our artist list can not only display data but also dynamically load information about each artist from a remote application. All of this happens on the fly, without the need to refresh the entire application. Thus, we have created a fully functional application consisting of several independent micro frontends, each of which handles its own task and can be reused in other projects.

Voila! 🎉

State Sharing in Micro Frontends

Sharing state between micro frontends can be challenging, as each micro frontend operates independently. In the previous example, we used props to pass data between micro frontends. However, depending on your application architecture and requirements, other state-sharing methods might be useful. Let's explore several approaches and how they can be applied in the context of module federation and micro frontends.

1. LocalStorage

localStorage can be handy for sharing data between micro frontends if you need to persist state between sessions. Each micro frontend can read and write to localStorage, allowing them to maintain common data.

2. Custom Events

Using CustomEvent to share data between micro frontends allows you to dispatch events with data and subscribe to these events in other micro frontends.

Usage Example:

// Dispatch an event in one micro frontend
const event = new CustomEvent(
  'artistSelected',
  { 
    detail: { 
      mbid: '123',
      imgUrl: 'http://example.com/image.jpg'
    }
  }
);
window.dispatchEvent(event);

// Subscribe to the event in another micro frontend
window.addEventListener('artistSelected', (event: CustomEvent) => {
  const { mbid, imgUrl } = event.detail;
  // handle artist selection...
});

This method enables decoupled communication between micro frontends, but managing a large number of events can make the code more complex.

3. Message Bus

A Message Bus is a messaging system that allows different micro frontends to exchange data. You can use libraries like postal.js or eventbus for this purpose.

Example using postal.js:

// Publish a message in one micro frontend
postal.publish({
  channel: 'artist',
  topic: 'selected',
  data: {
    mbid: '123',
    imgUrl: 'http://example.com/image.jpg' 
  }
});

// Subscribe to the message in another micro frontend
postal.subscribe({
  channel: 'artist',
  topic: 'selected',
  callback: (data) => {  
    const { mbid, imgUrl } = data;  
    // handle artist selection...
  }
});

The Message Bus provides flexibility in managing messages, but it may require additional setup and maintenance.

4. React Context

React Context can be used to pass data within a single application or between micro frontends if they share the same execution context. This is convenient if the micro frontends are embedded in a single application and operate within the same component tree.

Usage Example:

// Create a context
const ArtistContext = React.createContext(null);

// Context provider
export const ArtistProvider: React.FC = ({ children }) => {
  const [artist, setArtist] = React.useState({ mbid: '', imgUrl: '' });

  return (  
    <ArtistContext.Provider value={{ artist, setArtist }}>  
      {children}  
    </ArtistContext.Provider>
  )
}

// Use the context in another component
import ArtistContext from "shared/ArtistContext";
const ArtistDetails: React.FC = () => {
  const { artist } = React.useContext(ArtistContext);
  // render artist details...
}

React Context is effective for sharing state within a single application, but for micro frontends loaded via module federation, it may be less practical.

5. State Managers

Modern state managers like Redux, Zustand, or Recoil provide powerful state management capabilities. They allow centralized state management and can be used to share data between micro frontends.

Example using Zustand:

import create from 'zustand';

// Create the store
export const useArtistStore = create((set) => ({
  artist: {
    mbid: '',
    imgUrl: ''
  },
  setArtist: (artist) => set({ artist })
}));

// Set state in one micro frontend
import { useArtistStore } from "shared/stores";
const setArtist = useStore((state) => state.setArtist);
setArtist({ mbid: '123', imgUrl: 'http://example.com/image.jpg' });

// Read state in another micro frontend
import { useArtistStore } from "shared/stores";
const artist = useStore((state) => state.artist);

Choosing the right method depends on your application architecture and the interaction requirements between micro frontends. It’s important to evaluate each method based on the specific needs of your project.

Conclusion

In conclusion, micro frontends allow teams to break down monolithic applications into smaller, manageable parts, each of which can be independently developed and deployed. By leveraging Vite's fast build tools and React's component-based architecture, along with Webpack's Module Federation, developers can seamlessly integrate and share code across different parts of their application. Whether you're sharing state via props, localStorage, or more advanced patterns like a message bus, micro frontends offer tremendous flexibility. As micro frontends continue to grow in popularity, mastering these techniques will help you build scalable, maintainable, and performant web applications.

I hope this guide has been helpful and inspiring for your own micro frontend projects.

DEV Community: Nikita Bogachenkov

Dive into Next.js Parallel & Intercepting Routing: Enhancing UX

Parallel Routes

Benefits of Parallel Routes

Soft and Hard Navigation

When to Use Parallel Routes?

Intercepting Routes: Adding Context to Navigation

Intercepting Route Notations

How Does This Work in Practice?

Dive into Next.js App Router: Building Dynamic, Nested, and Static Pages

Meet the App Router: A New Era of Routing in Next.js

A Brief History: Pages Router vs. App Router

App Router: A Different Approach

App Router File Structure: Layouts, Pages, Error Handling, and More

layout.tsx — Page Layouts

page.tsx — Page Component

loading.tsx — Loading Indicator

not-found.tsx — Not Found Page

error.tsx — Local Error Handling

global-error.tsx — Global Error Handling

route.ts — API Endpoints

template.tsx — Layout Re-rendering

default.tsx — Parallel Route Fallback

The app Directory Structure: Grouping, Dynamic Routes, and Routing

Route Grouping - (folder)

Dynamic Routes

[folder] — Dynamic Segment:

[...folder] — Catch-all Segment:

[[…folder]] — Optional Catch-all Segment:

_folder - Private Folders

Params & Search Params: Managing URLs on the Fly

Params: Dynamic URL Segments

Search Params: Query Parameters in the URL

Combo: Params + Search Params

Full Control Over Every Aspect of the URL

Static Rendering vs. ISR in Pages Router & App Router

Pages Router: Static Rendering and ISR

App Router: Flexibility and Dynamism

Why does this happen?

How does this impact performance?

Caching Requests in the App Router: Why and How?

1. Using the Next.js fetch API

2. The Experimental Approach: unstable_cache

Cache Control = Performance Control

Dive into Next.js Server Actions: Simplifying Data Fetching & Mutations

How to Create a Server Action

Using Server Actions for Mutations

Cache Management: revalidatePath and revalidateTag

Fetching Data with Server Actions

Using Server Actions with Forms

Dive into Next.js Server Components: Unlocking Performance & Scalability

The Power of Server Components

How Server Components Work in Next.js

Anything Imported in a Client Component Becomes Client-Side

Dive into Next.js Server-Side Rendering (SSR): From SPA to ISR

Performance Optimization: Speeding Things Up and Keeping Users Happy

SSR: How Server-Side Rendering Changes the Game

The Evolution of React Applications: From SPA to SSR

The Evolution of SSR: SSG and ISR

1. Static Site Generation (SSG) — Build-Time Rendering

2. Incremental Static Regeneration (ISR) — Dynamic Generation on Request

SSR and Its Optimization Horizons

Memoization in React: When It Helps and When It Hurts

Virtual DOM and the rendering process

Re-rendering and how to avoid it

How to avoid unnecessary re-renders?

When memoization is unnecessary?

When memoization is useful:

Building Micro Frontends with Vite, React, and TypeScript: A Step-by-Step Guide

Table of Contents

What are Micro Frontends and Module Federation?

About the Application

Types Sharing

Step 1: Creating an npm Package

Step 2: Adding Interfaces

Step 3: Modules for React Components

Remote Application #1 - UI Components

Remote Application #2 - Artist Details

Host Application - Artist List

State Sharing in Micro Frontends

`layout.tsx` — Page Layouts

`page.tsx` — Page Component

`loading.tsx` — Loading Indicator

`not-found.tsx` — Not Found Page

`error.tsx` — Local Error Handling

`global-error.tsx` — Global Error Handling

`route.ts` — API Endpoints

`template.tsx` — Layout Re-rendering

`default.tsx` — Parallel Route Fallback

The `app` Directory Structure: Grouping, Dynamic Routes, and Routing

Route Grouping - `(folder)`

`[folder]` — Dynamic Segment:

`[...folder]` — Catch-all Segment:

`[[…folder]]` — Optional Catch-all Segment:

`_folder` - Private Folders

1. Using the Next.js `fetch` API

2. The Experimental Approach: `unstable_cache`

Cache Management: `revalidatePath` and `revalidateTag`