This document aims to help Korean users learning Framer mitigate the difficulties caused by a lack of Korean resources. We translated the official blog content into Korean and added practical information. We hope this provides some assistance to you using Framer.

The Dilemma of Framer and Custom Code

Framer is fundamentally a no-code website building tool. However, every site is essentially an app built with React, and users can add custom React components or overrides at any time.

Here's where the problem arises. What if a component causes errors in a React app? The entire structure can break, leaving a blank white screen.

Framer sites used to work like this. If even one piece of custom code was incorrect, the whole site would stop working. To fix this, we started a new approach this winter. The goal was to hide just the faulty component, allowing the rest of the site to function normally even if custom code breaks.

Now, let's dive into how to handle React errors properly.

Level 1: Error Boundaries

On the surface, Error boundaries in React exist precisely for such situations. They wrap around each custom code component to capture → render → finish with null (empty value), effectively hiding the error-prone parts.

class ErrorBoundary extends React.Component {
  static getDerivedStateFromError(error) {
    return { hasError: true }
  }

  render() {
    return this.state.hasError ? null : this.props.children
  }
}

Wrapping each custom code component in this manner ensures that if an error occurs, it only renders null, keeping the rest of the code safe. But there is still an issue here.

React Error Boundaries only work on the client-side. They are completely ignored during server-side rendering. So if server rendering fails, the page itself can't be optimized, and performance degrades.

Level 2: Suspense

In server rendering, React ignores error boundaries. Instead, if a server-side error occurs, React looks for the nearest <Suspense> boundary to render substitute code.

Thus, to hide faulty components, you need dual error boundaries for both client and server.

class ClientErrorBoundary extends React.Component {
  // 위와 동일
}

function ServerErrorBoundary({ children }) {
  return <Suspense fallback={null}>{children}</Suspense>
}

function ErrorBoundary({ children }) {
  return (
    <ServerErrorBoundary>
      <ClientErrorBoundary>
        {children}
      </ClientErrorBoundary>
    </ServerErrorBoundary>
  )
}

However, wrapping all code in <Suspense> presents a few challenges. It performs several tasks beyond just catching server-side errors.

Level 3: The Many Actions of Suspense

<Suspense> isn't just for catching errors; it executes various tasks simultaneously. By 2025, <Suspense> roughly provides the following features:

• <Suspense> Server:

  1. Renders substitute code when something is suspended (can skip with stream.allReady)

  2. Renders substitute code on error occurrence

• <Suspense> Client:

  1. Renders substitute code when something is suspended (can skip with startTransition())

  2. Supports selective and concurrent hydration

What happens if user code is suspended during rendering?

export function MyCodeComponent() {
  const weather = use(weatherPromise)
  return <div>It’s {weather.temperature}° outside!</div>
}

On the server, you can wait with stream.allReady until code exits its suspended state.

However, on the client, it's different. If a component stops, <Suspense> within <ServerErrorBoundary> temporarily renders null as substitute code, causing the component to disappear and reappear visually.

If the code surrounding a component executes within startTransition, this flicker can be avoided, but we can't control user code. Consequently, users experience poor UX as components disappear momentarily while data is fetched.

How can this issue be resolved?

One method could be to avoid rendering <ServerErrorBoundary> on the client entirely. However, this causes hydration mismatches.

This is because <ServerErrorBoundary> renders <Suspense> internally. While <Suspense> doesn't create actual DOM elements, it outputs special comments (<!--$-->, etc.).

The server-generated comments must be correctly identified as matching by the client during hydration, but removing <ServerErrorBoundary> on the client removes those comments. React then concludes