DEV Community: Maria Kim

Perfecting the Loading Experience with next/dynamic and React Suspense

Maria Kim — Mon, 17 Mar 2025 05:22:11 +0000

Introduction

In Next.js, you can speed up your app and provide a better user experience by lazy loading components. The official docs for next/dynamic describe it as a “composite of React.lazy() and Suspense.”

However, in practice, it differs in a few important ways—especially when data fetching is involved. Let’s dive in and see how next/dynamic works, why you’d combine it with React Suspense, and what really happens during server and client rendering.

1. next/dynamic in a Nutshell

Client-Only Execution: Even if your component has 'use client', Next.js still attempts a minimal server render (generating some HTML) unless you explicitly disable SSR with ssr: false. Using next/dynamic with ssr: false forces the component to only render on the client.
Lazy Loading: It splits the bundle, loading the component only when needed.
Custom Loading UI: The loading option provides a placeholder while the imported component is being downloaded from the server.

Example:

const LazyLoadedComponent = dynamic(() => import('./MyComponent'), {
  ssr: false,
  loading: () => <p>Loading component...</p>,
});

In this setup, Next.js will not server-render MyComponent; it sends a minimal placeholder to the browser. Only once the JavaScript for MyComponent is downloaded does it render.

2. next/dynamic vs. React.lazy() and Suspense

The docs mention: “next/dynamic is a composite of React.lazy() and Suspense.”

The reality: While next/dynamic harnesses a similar underlying mechanism to chunk-split components, it does not automatically suspend on data-fetching Promises. Instead:

If you’re fetching data within a dynamically imported component (e.g., using React Query’s useSuspenseQuery), React Suspense needs to handle that separately from the dynamic import’s loading UI.

Hence, you might still see two different loading states if you’re not careful:

One for component import (handled by next/dynamic loading).
Another for data loading (handled by Suspense fallback when your data-fetching hook suspends).

3. Why Use Suspense at All?

React Suspense provides a unified way to handle asynchronous operations, such as data fetching or component loading. If your dynamically imported components also fetch data with Suspense-friendly libraries (like React Query’s useSuspenseQuery), you can wrap them in a boundary to have a single fallback UI for both component loading and data loading.

'use client';

import { Suspense } from 'react';
import dynamic from 'next/dynamic';

import { useClientStore } from '@/providers/client-store-provider';
import PantryBoxesSkeleton from './PantryBoxes/PantryBoxesSkeleton';

// Forcing client-only rendering and a placeholder while the import downloads
const GuestUserPantry = dynamic(() => import('./GuestUserPantry'), {
  ssr: false,
  loading: PantryBoxesSkeleton,
});
const LogInUserPantry = dynamic(() => import('./LogInUserPantry'), {
  ssr: false,
  loading: PantryBoxesSkeleton,
});

export default function Pantry() {
  // Example: Zustand store check
  const isLoggedIn = useClientStore((state) => state.user.isLoggedIn);

  // Dynamically pick the right component
  const Component = isLoggedIn ? LogInUserPantry : GuestUserPantry;

  return (
    <Suspense fallback={<PantryBoxesSkeleton />}>
      <Component />
    </Suspense>
  );
}

Here:

PantryBoxesSkeleton is shown while the component is being dynamically imported.
If GuestUserPantry or LogInUserPantry suspends while fetching data, falls back to PantryBoxesSkeleton again until data resolves.
The result is a single consistent skeleton UI, avoiding multiple flickering loaders.

4. Key Takeaways & Best Practices

Use next/dynamic for True Client-Only Components
Setting ssr: false ensures Next.js doesn’t attempt to render on the server at all, especially handy for code that is purely browser-specific (e.g., accessing window or localStorage).
Combine next/dynamic with Suspense for Seamless Fallback
- loading in next/dynamic covers the import phase.
- Suspense fallback covers data fetching or any other asynchronous tasks in the child component.
Beware of Double Loading States
If you don’t unify your placeholders, users might see one loading UI for dynamic imports and another loading state for data fetching. Reuse the same fallback wherever possible.
Understand That next/dynamic and React.lazy() Differ
Even though the docs liken them, next/dynamic is a Next.js abstraction that doesn’t automatically tie into Suspense’s data-fetching logic. They can work together, but they address different parts of the lazy-loading process.

Conclusion

While Next.js’s next/dynamic is often described as a “composite” of React.lazy() and Suspense, it does not handle data-fetching Promises the way Suspense does. Instead, it’s best to use both: let next/dynamic handle component-level lazy-loading, and let React Suspense handle asynchronous data loading behind the scenes. This dual approach ensures a consistent loading placeholder and a smoother user experience—with minimal flickers and streamlined hydration on the client.

That’s it! By combining next/dynamic (with ssr: false) and React Suspense, you’ll avoid any “double loading” confusion and deliver a polished, high-performance Next.js application. Happy coding!

Next.js — Can we make an Intercepting Route behave like ISR?

Maria Kim — Tue, 25 Feb 2025 11:51:19 +0000

Definitions

What is Incremental Static Regeneration

• Closely related to SSG and pages that are revalidated either at build time or at runtime.
• Lets you update static content without having to rebuild your entire site.
• Reduces server load by serving most requests with pre-rendered static pages.
• Automatically applies proper cache-control headers to pages.
• The value specified in revalidate will automatically be applied to any fetch calls in the page as the cache-control revalidate value.
• ⚠️ However, if you set fetch to use the force-cache option, the automatic setting is ignored. In that case, you need to manually specify the revalidate option.
• Lets you handle large numbers of pages without incurring a long next build time.
• If you add generateStaticParams, then dynamicParams is automatically set to true.
• During the build, only the pages for parameters defined in generateStaticParams are generated.
• If a request comes in at runtime with a parameter that wasn't included in generateStaticParams, the page will be generated at that time and revalidation will be applied.

🔗 References:

What are Intercepting Routes?

• Designed to dynamically load content.
• Allows you to show new content without leaving the current layout or navigating to a different route.
• Because of that, Intercepting Routes cannot be used with ISR.

🔗 Reference:

Next.js Docs - Intercepting Routes

How Does Next.js Handle Caching?

Caching Types

Next.js has different caching layers:

• Persistent (but revalidatable) server-based caches include the Full Route Cache and the Data Cache.
• However, the Full Route Cache requires storing HTML and RSC payloads. That means it is generally used when an actual route can be cached, like with SSG or ISR.
• So if you want to cache responses in a way similar to SSG/ISR (for incoming requests), your only option is the Data Cache.

🔗 Reference:

Next.js Docs - Caching

The Question

Can we make an Intercepting Route behave like ISR?
• Is it possible to use ISR for Intercepting Routes?
As noted above, Intercepting Routes only alter the address within the current layout rather than serving an entirely separate page route. Therefore, they cannot be cached as an ISR page.

• What does "behave like ISR" really mean?
In many cases, it means:

Caching data as much as possible.
Using the latest data after a specified interval. Let's look into how we can address these requirements.

The Core Issues to Solve

1. Caching data as much as possible**

Revisiting the available caches in Next.js, we can categorize them by storage location and lifespan:

1. Server + Persistent (revalidatable)
• Full Route Cache
• Data Cache

2. Server + Within a single request
• Request Memoization

3. Client-Side
• Router Cache

The caches that live on the server and can persist across multiple requests are Full Route Cache and Data Cache. However, because Full Route Cache stores the HTML/RSC for entire pages (as with SSG/ISR), that option isn't suitable for Intercepting Routes.

That leaves the Data Cache as our tool of choice.

2. Using fresh data at a specified interval

To leverage Data Cache, you can use the fetch option in Next.js:

fetch('url', {
  cache: 'force-cache',
  next: {
    revalidate: 86400, // 1 day in seconds
  },
});

Here, you set the cache behavior to force-cache, and specify a revalidate interval (in seconds) within the next property. This allows Next.js to revalidate your data cache at the given interval, effectively mimicking the "ISR-like" behavior of periodically refreshing your data - without actually using a separate ISR route.

🔗 Reference:

Next.js Docs - Caching

That's how you can approximate ISR-like caching and revalidation for Intercepting Routes. While you can't truly make them into ISR pages, you can still benefit from Next.js's Data Cache to cache and periodically refresh the data used within those routes.

Using Emotion in a New Project: Component Inheritance vs. Single Styled Component with Props

Maria Kim — Tue, 25 Feb 2025 11:31:51 +0000

I was creating shared (common) components using Emotion in a new project. As I was considering how best to structure things for cleanliness and scalability, I happened to watch a YouTube video about the SOLD principle. That video led me to think that developing shared components using style inheritance could be advantageous for future expansion.

So I changed all my shared components to use extension (inheritance). However, I encountered an unexpected bug in the process. Through this bug, I learned the difference between:

Extending (inheriting) components
Using branching within a single styled component

And I'd like to share that experience here.

Two Ways to Handle Variations in Components

1. Using Inheritance (Extend)

Create a base styled component.
For each needed variant, extend that base component and apply different styles.
If you have many variants, adding new ones is straightforward since it simply involves creating more extended components.

2. Handling Branching within a Single Styled Component

Pass a value like variant as a prop.
In a single styled component, use conditionals such as switch or ternary operators to apply different styles.
This approach handles frequently changing props dynamically and immediately.

Simple Example Code Comparison

1. Handling Variants with Inheritance

function Button({ variant = "primary", disabled, children }: ButtonProps) {
  const Component = ButtonComponent[variant];
  return <Component disabled={disabled}>{children}</Component>;
}

const StyledButtonBase = styled.button`
  /* Common styles */
`;

const PrimaryButton = styled(StyledButtonBase)`
  background-color: black;
  color: white;
`;

const DangerButton = styled(StyledButtonBase)`
  background-color: red;
  color: white;
`;

const ButtonComponent = {
  primary: PrimaryButton,
  danger: DangerButton
};

• When a new variant is added, you extend StyledButtonBase again (for example, DangerButton) and can easily keep expanding.

2. Handling Branching within a Single Styled Component

function Button({ variant = "primary", disabled, children }: ButtonProps) {
  return (
    <StyledButton variant={variant} disabled={disabled}>
      {children}
    </StyledButton>
  );
}

const StyledButton = styled.button<ButtonProps>`
  /* Common styles */
  background-color: ${(props) => getBackgroundColor(props)};
  color: ${(props) => getColor(props)};
`;

function getBackgroundColor({ variant, disabled, theme }: ButtonProps & { theme: Theme }) {
  switch (variant) {
    case "primary":
      return blue;
    case "danger":
      return red;
    default:
      return gray;
  }
}

function getColor({ variant, disabled, theme }: ButtonProps & { theme: Theme }) {
  switch (variant) {
    case "primary":
      return white;
    case "danger":
      return white;
    default:
      return black;
  }
}

*This is not a good example. The button color may change depending on the state after the button component is mounted. Instead of this approach, it is better to use Styled Component inheritance when there are design variations, such as a Background button and a Border button.

The Problem Scenario

Let's say we have an InputContainer component that wraps an input. When the input's value changes (onChange), we perform a validation check. If there's an error, we pass variant='error' to change the border color to red.

Inheritance-Based InputContainer

function InputContainer({ variant = "default", children }: InputContainerProps) {
  const Component = InputContainerComponent[variant];
  return <Component>{children}</Component>;
}

const BaseInputContainer = styled.div`
  border: 1px solid black;
`;

const ErrorInputContainer = styled(BaseInputContainer)`
  border-color: red;
`;

const InputContainerComponent = {
  default: BaseInputContainer,
  error: ErrorInputContainer,
};

Consider that a re-render takes place. What potential issue could arise here?

Handling Branching within a Single Styled Component InputContainer

function InputContainer({ variant = "default", children }: InputContainerProps) {
  return (
    <StyledInputContainer variant={variant}>
      {children}
    </StyledInputContainer>
  );
}

const StyledInputContainer = styled.div<{ variant: "default" | "error" }>`
  border: 1px solid
    ${({ theme, variant }) =>
      variant === "error" ? theme.colors.variants.negative : theme.colors.neutral.gray300};
  /* ... */
`;

What differences do you see in how the component is re-rendered?

The Bug I Encountered

I experienced a bug where the input's focus would disappear every time the border color changed.

Why Did This Happen?

In the inheritance-based approach, changing the variant creates what is effectively a new component each time. So when variant changes from "default" to "error", React sees the old component unmount and a new one mount. As a result, the original input element is removed, and a new one is created, causing the loss of focus.

What about the branch inside style approach?

With props, you're still dealing with the same component. Only the class or inline styles change. Because the same DOM node persists, the focus doesn't get lost when the border color changes.

Summary

Inheritance-Based InputContainer

• When the variant changes, a different component is rendered.
• React may treat it as a completely separate DOM element and re-mount it, depending on the complexity of the structure.
• If you had an input focused inside, it can lose focus due to re-mount.

Branch inside style InputContainer

• When the variant changes, the same component remains; only the styling changes.
The focused input remains intact, preserving the focus.

Conclusion & Recommendations

When Should You Use Inheritance?

• The prop that determines branching will never change after the component mounts.
• For example, a Button component with multiple design variations (e.g., Border, Background, etc.).
• Inheritance aligns well with the Open-Closed Principle, allowing new variants to be added without modifying existing code.

When Should You Use Props-Based Branching?

• When there's a lot of user interaction and the variant or disabled states change frequently.
• For example, form inputs that can switch to an error state in real-time.
• Because the component doesn't unmount and remount, states like focus are maintained.

In the case of Emotion, you can define only the class separately, allowing for extension in accordance with the Open-Closed Principle

By using Emotion’s css utility as shown below, you can apply the Open-Closed Principle by changing only the class.

import { css } from "@emotion/react";
import styled from "@emotion/styled";

import theme from "@/styles/theme";

export type InputVariant = "default" | "error";

interface InputContainerProps {
  children: React.ReactNode;
  className?: string;
  variant?: InputVariant;
}

function InputContainer({
  children,
  className,
  variant = "default",
}: InputContainerProps) {
  return (
    <StyledInputContainer variant={variant} className={className}>
      {children}
    </StyledInputContainer>
  );
}

export default InputContainer;

interface StyledInputContainerProps {
  variant: InputVariant;
}

const StyledInputContainer = styled.div<StyledInputContainerProps>`
  display: flex;
  padding: 11px 18px;
  justify-content: space-between;
  border-radius: 5px;
  background: ${({ theme }) => theme.colors.neutral.white};
  ${({ variant }) =>
    CustomInputContainer[variant] ?? CustomInputContainer.default};
`;

const defaultInputContainer = css`
  border: 1px solid ${theme.colors.neutral.gray100};
`;

const errorInputContainer = css`
  border: 1px solid ${theme.colors.variants.negative};
`;

const CustomInputContainer: Record<
  NonNullable<InputContainerProps["variant"]>,
  typeof defaultInputContainer
> = {
  default: defaultInputContainer,
  error: errorInputContainer,
};

Final Summary

For components with frequent real-time UI changes: Handle branching within a single component.
For components that do not change dynamically after mounting and need to be extended with multiple types: Use inheritance.
If necessary, you can mix both approaches. For example, for a Button component, you can distinguish broad categories (such as design differences like Border and Background) using inheritance, while handling more detailed state changes (such as error or success) via props.

Ultimately, it's crucial to understand "when the UI changes". I hope this post helps you design shared components with Emotion more effectively!

Thank you!

Why Zustand State Reset Works Instantly, But React Query Cache Clearing Can Be Tricky

Maria Kim — Tue, 25 Feb 2025 11:20:33 +0000

When working with state management and data-fetching libraries in React applications, you might encounter an interesting behavior difference during logout flows or similar global state resets. Specifically, if you use Zustand to manage user state and React Query to manage server-side data, you might notice that resetting Zustand's state works seamlessly, but clearing React Query's cache sometimes requires extra care. This blog will explain why this happens and how to handle it properly.

A Common Logout Example

Imagine you have a logout function like this:

const onLogout = async () => {
 await logout(); // logout api
 resetUser(); // Zustand code to clear user state
 queryClient.clear(); // React Query code to clear cache
 router.push('/home'); // Navigate away
};js

At first glance, this looks fine. However, in practice, you might encounter inconsistent behavior with React Query's cache clearing, especially when navigating away (router.push()).

You might end up doing something like this instead:

const onLogout = async () => {
 await logout();
 resetUser(); // Zustand state reset
 Promise.resolve().then(() => queryClient.clear()); // React Query cache clear
 router.push('/home');
};

Why does deferring the queryClient.clear() call with Promise.resolve() sometimes work better? And why is Zustand's resetUser() always fine?

Key Difference: Zustand vs. React Query

🐻 Zustand - Simple Synchronous State Update

When you call resetUser() in Zustand, it:

Mutates the store state synchronously.
Notifies all subscribed components to re-render if necessary.
Ignores unmounted components since they are no longer subscribed.

🔥 React Query - Cache, Observers, and Side Effects

When you call queryClient.clear(), it:

Invalidates and removes query data from the cache.
Notifies active subscriptions (e.g. components using useQuery() hooks).
Handles ongoing network requests, retries, and refetches (if applicable).

The key problem is that if components are in the process of unmounting (e.g., due to router.push()) while queryClient.clear() is running, you can get into a race condition:

Components might unsubscribe while React Query is still notifying them.
Ongoing network requests might still resolve after you clear the cache.
React Query hooks might still trigger updates for unmounted components.

What is a Race Condition?

A race condition happens when two or more operations happen at the same time, and the final outcome depends on the timing or order of those operations. In this case, clearing the React Query cache and unmounting components due to routing can overlap, leading to unexpected behavior or errors.

Why Deferring Works

When you do this:

Promise.resolve().then(() => queryClient.clear());

You defer the cache clearing to the next microtask. This allows React to:

Finish unmounting components triggered by router.push().
Unsubscribe any React Query observers tied to those components.
Safely clear the cache afterward, without interfering with ongoing React lifecycle processes.

Why Zustand Is Always Safe

Zustand's state update is synchronous and not lifecycle-sensitive:

If you call resetUser() and a component is still mounted, it re-renders.
If the component is unmounted, it has already unsubscribed, and nothing happens.
There's no async behavior or network lifecycle management to interfere.

Because of this simplicity, you can reset Zustand state at any time without worrying about navigation or component lifecycles.

Summary Table

Final Thoughts

Understanding the difference between local synchronous state (Zustand) and asynchronous data-fetching state (React Query) is crucial when designing logout flows or global state resets. Zustand's simplicity allows for carefree state updates, while React Query requires more attention to lifecycle timing.

When in doubt, defer cache clearing to ensure it runs after routing transitions complete. This small adjustment can save you from subtle race conditions and improve your app's stability.

Happy coding! 🚀