Forem: Max

Top Tools for React Server-Side Rendering Applications

Max — Mon, 06 Jan 2025 17:31:47 +0000

Top Tools for React Server-Side Rendering Applications

Server-Side Rendering (SSR) is a powerful technique to enhance your website's performance and user experience, but it’s not always the right choice. Understanding when SSR is truly needed and which tools to use can significantly impact your project's success.

In my previous articles, we explored how to build your own SSR with React from scratch. Now, we’ll dive into when you should consider creating a custom solution and when it’s better to rely on a ready-made tool with built-in SSR capabilities.

What is SSR
- Key Benefits
- Challenges
When to Use SSR
- Ideal Scenarios
- Limitations
- Is SSR the Right Choice?
Tools
- Next.js
- Remix
- Vike (Vite Plugin SSR)
- Custom SSR
- Server Components
Comparison Table
Conclusion

What is SSR

Server-side rendering (SSR) is a technique in web development where the server generates the HTML content of a web page before sending it to the browser. Unlike traditional client-side rendering (CSR), where JavaScript builds the content on the user's device after loading an empty HTML shell, SSR delivers fully-rendered HTML right from the server.

Key benefits

Improved SEO: Since search engine crawlers receive fully-rendered content, SSR ensures better indexing and ranking.
Faster First Paint: Users see meaningful content almost immediately, as the server handles the heavy lifting of rendering.
Enhanced Performance: By reducing the rendering workload on the browser, SSR provides a smoother experience for users on older or less powerful devices.
Seamless Server-to-Client Data Transfer: SSR allows you to pass dynamic server-side data to the client without rebuilding the client bundle.

Challenges

Increased Server Load: Rendering pages on the server increases resource usage, especially for high-traffic sites.
Latency Concerns: Each page request requires server-side processing, potentially slowing down response times compared to static pages.
Complexity: Managing SSR, hydration, and caching strategies adds complexity to the development process.

When compared to Static Site Generation (SSG) and Client-Side Rendering (CSR), SSR offers a balanced approach for dynamic, content-rich applications that prioritize performance and SEO. Modern frameworks also support hybrid techniques like Incremental Static Regeneration (ISR), combining the speed of pre-rendered pages (SSG) with the flexibility of server-side rendering (SSR) for dynamic updates.

When to Use SSR

Server-Side Rendering is a powerful tool, but it’s not the ideal solution for every use case.

Ideal Scenarios

SEO-Critical: Applications that depend heavily on search engine visibility
- E-commerce platforms
- Blogs
- Marketing pages
- News
Dynamic, Real-Time Content: Applications requiring frequently updated or live data
- Social networks
- Dashboards
- Live event pages
Improving Initial Load Performance
- Users on slow networks or older devices
- Large-scale applications with complex UI components

Limitations

Static Content: Static Site Generation (SSG) is usually sufficient
- Landing pages
- Documentation sites
- Portfolio websites
High-Traffic Applications: SSR increases server load since each request involves server-side processing. Consider SSG or caching strategies for scalability
- Viral content
- Pages with millions of daily hits
Heavy Client-Side Interactivity: Applications relying on extensive client-side interactions
- Complex dashboards with data manipulation
- Apps with advanced animations or transitions
Privacy or Personalization Concerns: SSR can increase complexity and security risks when rendering user-specific data on the server.
Budget or Infrastructure Limitations: SSR requires more resources and infrastructure compared to SSG or CSR.

Is SSR the Right Choice?

Does your app rely on SEO for visibility?
Do you need real-time updates or frequently changing content?
Are your users on slow networks or older devices where faster initial loading matters?
Does your app involve complex UI components that benefit from a fast first paint?

Tools

Several frameworks and tools simplify the implementation of SSR in React applications. Below are some of the most popular options, each with its unique strengths.

Next.js

Created in 2016 | nextjs.org

A full-stack React framework with build-in SSR, SSG and ISR, with handling API routes and routing capabilities.

Pros:
- Easy to set up with a rich developer experience.
- Built-in hybrid rendering (SSR, SSG, ISR) with React Server Components support.
- Extensive ecosystem, plugins and integrations.
- Great scalability for high-traffic applications.
Cons:
- Opinionated structure can limit flexibility.
- Higher build times for large-scale projects compared to lighter solutions.
- Overkill for front-end-only projects.
Use Cases:
- E-commerce platforms with dynamic product pages.
- Marketing pages requiring SEO and fast loading.
- SaaS applications leveraging hybrid SSR and SSG.

Remix

Created in 2021 | remix.run

A performance-focused React framework emphasizing server-side routing, streaming SSR and web-native APIs.

Pros:
- Nested routing and granular data fetching.
- Streaming SSR for fast time-to-first-byte (TTFB).
- Modern web standards with features like Fetch and Web Streams.
- Strong focus on performance and real-time data handling.
Cons:
- Smaller ecosystem compared to Next.js.
- Learning curve for web-native APIs and streaming SSR.
- Lacks built-in incremental regeneration features like ISR.
- Does not yet have full support for React Server Components (Jan 2025).
Use Cases:
- Content-heavy platforms like blogs and news sites.
- Dynamic, real-time applications with frequent updates.
- SEO-critical projects requiring fast rendering and routing.
- Applications that need highly flexible routing and performance optimization.

Vike (Vite Plugin SSR)

Created in 2021 | vike.dev

A lightweight plugin for adding SSR to Vite-powered React applications. Known for its simplicity, speed, and modern tooling.

Pros:
- Lightweight and fast setup with Vite’s tooling.
- Highly customizable for specific SSR requirements.
- Ideal for developers familiar with Vite’s ecosystem.
Cons:
- Smaller ecosystem compared to Next.js or Remix.
- Lacks advanced built-in features like routing or API handling.
- Requires manual effort for common SSR tasks.
- Does not yet have full support for React Server Components (Jan 2025).
Use Cases:
- Lightweight apps needing fast SSR setups.
- Projects focusing on speed and customization.
- Small-to-medium-sized apps with limited complexity.
- Seamless migration from a CSR Vite project to an SSR-enabled setup.

Custom SSR

renderToString | renderToPipeableStream

Building a custom server-side rendering solution using React’s APIs for full control over rendering logic and behavior.

Pros:
- Maximum flexibility and control over rendering.
- No dependency on external frameworks or tools.
- Tailored optimizations for unique project requirements.
Cons:
- High development and maintenance cost.
- Steep learning curve for those unfamiliar with SSR concepts.
- Scalability challenges unless paired with robust caching and infrastructure.
- You must implement RSC support yourself, adding to complexity.
Use Cases:
- Applications with unique SSR needs not covered by existing frameworks.
- Research or educational projects exploring SSR internals.
- Performance-critical apps needing tailored optimizations.

Server Components

Created in 2021 | react.dev

React Server Components (RSC) are a React feature designed for server-first rendering with minimal client-side JavaScript. While they are not the same as full SSR, they require a server environment to function properly. This enables advanced capabilities like streaming responses and progressive hydration, without needing a full SSR setup.

In simple terms, RSC are components that run on the server and send only HTML to the client, unlike SSR which renders the entire component tree. These components are excluded from the client-side build, reducing the JavaScript payload.

You can use RSC without relying on frameworks, but setting up the necessary functionality yourself can be time-consuming and complex. For a smoother experience, I recommend using Next.js, which provides built-in support for RSC.

Pros:
- Minimal JavaScript payload on the client, improving performance and load times.
- Supports streaming and incremental updates, reducing time-to-first-byte (TTFB).
- Future-proof and aligned with React’s long-term goals.
- Can be used independently of full SSR for server-optimized rendering.
Cons:
- Requires a server environment to render components, even without full SSR.
- Steep learning curve requiring developers to adapt to new paradigms.
- Still evolving, with limited community adoption compared to mature SSR frameworks.
Use Cases:
- Applications requiring server logic for specific components without full SSR setup.
- High-performance dashboards and content-heavy platforms needing real-time updates.
- Projects optimizing for long-term scalability and minimal client-side JavaScript.
- Hybrid applications combining server-optimized components with client-side interactivity.

Comparison Table

Tool	Use Cases	Ease of Use
Next.js	E-commerce, SaaS, marketing pages	Easy
Remix	Blogs, real-time apps, SEO projects	Moderate
Vike	Lightweight apps, CSR-to-SSR	Moderate
Custom SSR	Multi-tenant apps, gaming dashboards	Advanced
Server Components	Dashboards, scalable apps	Advanced

For most projects, Next.js or Remix are sufficient due to their comprehensive features and simplicity.

Vike is an excellent option for transitioning existing Vite projects to SSR.

Building a custom SSR setup is unnecessary overhead for the majority of projects unless your requirements are highly specialized. If you’re interested in building your own SSR from scratch, be sure to check out my previous articles in this series, linked at the bottom.

Server Components, as a built-in React feature, are best suited for scenarios requiring server-optimized rendering with minimal client-side JavaScript. However, for most real-world projects, I recommend using frameworks like Next.js with full built-in support.

Conclusion

In this guide, you’ve explored the React Server-Side Rendering ecosystem and gained the knowledge needed to implement SSR in your own projects. Always choose the right tool for the right purpose to maximize results.

This is part of my series on SSR with React. Stay tuned for more articles!

Building Production-Ready SSR React Applications
Advanced React SSR Techniques with Streaming and Dynamic Data
Setting Up Themes in SSR React Applications
Top Tools for React Server-Side Rendering Applications

Stay Connected

I’m always open to feedback, collaboration or discussing tech ideas — feel free to reach out!

linkedin/maxh1t

Setting Up Themes in SSR React Applications

Max — Sun, 05 Jan 2025 03:10:06 +0000

Imagine visiting a website that seamlessly adapts to your preferences — effortlessly switching between light, dark and system-based themes.

This article continues my series on SSR with React. In the basics article, we explored production-ready configurations, while in advanced techniques, we tackled challenges like hydration errors. Now, we’ll take it a step further by implementing robust theming support that integrates seamlessly with SSR.

Themes and SSR
Implementation
- Install Dependencies
- Add cookie to the Server Build
- Apply Themes on the Server
- Handle Themes on the Client
Conclusion

Themes and SSR

The main issue is the Initial Flash of Incorrect Theme (FOIT).

Essentially, themes are just about changing CSS variables. In most cases, you’ll work with three themes:

Light: The default set of CSS variables.
Dark: Applied when the <html> tag has the class dark.
System: Automatically switches based on the user's system preference, using the (prefers-color-scheme: dark) media query to determine if the theme should be dark or light.

By default, the server will render the HTML with the light theme and send it to the browser. If a user prefers the dark theme, they will see a visible theme change on the first page load, which disrupts the user experience.

There are two main ways to solve this issue:

Add a <script> tag in the HTML on server and set class dynamically on the client.
Use a cookie to store the user’s theme preference and set the class on the server.

The first solution is how the next-themes package works (Jan 2025). In this article, you’ll implement the cookie-based approach to ensure seamless theme handling in your SSR application.

Implementation

To implement themes, you’ll use two cookies:

serverTheme - Used to apply the correct class to the <html> tag.
clientTheme - Used to handle hydration errors.

The client always sets both cookies, ensuring the server can correctly render the appropriate theme on the next request.

This guide builds upon concepts introduced in the previous article, Building Production-Ready SSR React Applications, which you can find linked at the bottom. For simplicity, shared constants and types are not created here, but you can find their implementation in the example repository.

Install Dependencies

Install the required packages for cookie handling:

pnpm add cookie js-cookie

Install types for js-cookie:

pnpm add -D @types/js-cookie

If you’re not using react-router in your app, you can use the cookie package as a devDependencies.

Add cookie to the Server Build

Update your tsup configuration file:

// ./tsup.config.ts
import { defineConfig } from 'tsup'

export default defineConfig({
  entry: ['server'],
  outDir: 'dist/server',
  target: 'node22',
  format: ['cjs'],
  clean: true,
  minify: true,
  external: ['lightningcss', 'esbuild', 'vite'],
  noExternal: [
    'express',
    'sirv',
    'compression',
    'cookie', // Include the cookie in the server build
  ],
})

Apply Themes on the Server

Define Theme Constants

// ./server/constants.ts
export const CLIENT_THEME_COOKIE_KEY = 'clientTheme'
export const SERVER_THEME_COOKIE_KEY = 'serverTheme'

export enum Theme {
  Light = 'light',
  Dark = 'dark',
  System = 'system'
}

Apply Theme Class to Tag

Create a utility function to apply the correct theme class to the <html> tag based on the serverTheme cookie:

// ./server/lib/applyServerTheme.ts
import { parse } from 'cookie'
import { Request } from 'express'
import { SERVER_THEME_COOKIE_KEY, Theme } from '../constants'

export function applyServerTheme(req: Request, html: string): string {
  const cookies = parse(req.headers.cookie || '')
  const theme = cookies?.[SERVER_THEME_COOKIE_KEY]

  if (theme === Theme.Dark) {
    return html.replace('<html lang="en">', `<html lang="en" class="dark">`)
  }

  return html
}

Retrieve the Client Theme Cookie

Create a utility function to retrieve the clientTheme cookie

// ./server/lib/getClientTheme.ts
import { parse } from 'cookie'
import { Request } from 'express'
import { CLIENT_THEME_COOKIE_KEY, Theme } from '../constants'

export function getClientTheme(req: Request) {
  const cookies = parse(req.headers.cookie || '')

  return cookies?.[CLIENT_THEME_COOKIE_KEY] as Theme | undefined
}

Update Server Configurations for Theming

Development Configuration:

// ./server/dev.ts
import fs from 'fs'
import path from 'path'
import { Application } from 'express'
import { HTML_KEY } from './constants'
import { applyServerTheme } from './lib/applyServerTheme'
import { getClientTheme } from './lib/getClientTheme'

const HTML_PATH = path.resolve(process.cwd(), 'index.html')
const ENTRY_SERVER_PATH = path.resolve(process.cwd(), 'src/entry-server.tsx')

export async function setupDev(app: Application) {
  const vite = await (
    await import('vite')
  ).createServer({
    root: process.cwd(),
    server: { middlewareMode: true },
    appType: 'custom',
  })

  app.use(vite.middlewares)

  app.get('*', async (req, res, next) => {
    try {
      let html = fs.readFileSync(HTML_PATH, 'utf-8')
      html = await vite.transformIndexHtml(req.originalUrl, html)

      const { render } = await vite.ssrLoadModule(ENTRY_SERVER_PATH)
      // send Client Theme from cookie to render
      const appHtml = await render(getClientTheme(req))

      // Apply Server theme on template html
      html = applyServerTheme(req, html)
      html = html.replace(HTML_KEY, appHtml)

      res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
    } catch (e) {
      vite.ssrFixStacktrace(e as Error)
      console.error((e as Error).stack)
      next(e)
    }
  })
}

Production Configuration:

// ./server/prod.ts
import fs from 'fs'
import path from 'path'
import compression from 'compression'
import { Application } from 'express'
import sirv from 'sirv'
import { HTML_KEY } from './constants'
import { applyServerTheme } from './lib/applyServerTheme'
import { getClientTheme } from './lib/getClientTheme'

const CLIENT_PATH = path.resolve(process.cwd(), 'dist/client')
const HTML_PATH = path.resolve(process.cwd(), 'dist/client/index.html')
const ENTRY_SERVER_PATH = path.resolve(process.cwd(), 'dist/ssr/entry-server.js')

export async function setupProd(app: Application) {
  app.use(compression())
  app.use(sirv(CLIENT_PATH, { extensions: [] }))

  app.get('*', async (req, res, next) => {
    try {
      let html = fs.readFileSync(HTML_PATH, 'utf-8')

      const { render } = await import(ENTRY_SERVER_PATH)
      // send Client Theme from cookie to render
      const appHtml = await render(getClientTheme(req))

      // Apply Server theme on template html
      html = applyServerTheme(req, html)
      html = html.replace(HTML_KEY, appHtml)

      res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
    } catch (e) {
      console.error((e as Error).stack)
      next(e)
    }
  })
}

Handle Themes on the Client

Define Constants

Duplicate constants for client use or move them to a shared folder

// ./src/constants.ts
export const SSR = import.meta.env.SSR

export const CLIENT_THEME_COOKIE_KEY = 'clientTheme'
export const SERVER_THEME_COOKIE_KEY = 'serverTheme'

export enum Theme {
  Light = 'light',
  Dark = 'dark',
  System = 'system',
}

Create Theme Context

Set up a React context to manage theme state and provide theme management methods:

// ./src/theme/context.ts
import { createContext, useContext } from 'react'
import { Theme } from '../constants'

export type ThemeContextState = {
  theme: Theme
  setTheme: (theme: Theme) => void
}

export const ThemeContext = createContext<ThemeContextState>({
  theme: Theme.System,
  setTheme: () => null,
})

export const useThemeContext = () => useContext(ThemeContext)

Implement Theme Utilities

// ./src/theme/lib.ts
import Cookies from 'js-cookie'
import { CLIENT_THEME_COOKIE_KEY, SERVER_THEME_COOKIE_KEY, SSR, Theme } from '../constants'

// Resolve the system theme using the `prefers-color-scheme` media query
export function resolveSystemTheme() {
  if (SSR) return Theme.Light
  return window.matchMedia('(prefers-color-scheme: dark)').matches ? Theme.Dark : Theme.Light
}

// Update the theme cookies and set appropriate class to <html>
export function updateTheme(theme: Theme) {
  if (SSR) return

  const resolvedTheme = theme === Theme.System ? resolveSystemTheme() : theme

  Cookies.set(CLIENT_THEME_COOKIE_KEY, theme)
  Cookies.set(SERVER_THEME_COOKIE_KEY, resolvedTheme)

  window.document.documentElement.classList.toggle('dark', resolvedTheme === Theme.Dark)
}

// Get the default theme from cookies
export function getDefaultTheme(): Theme {
  if (SSR) return Theme.System
  const theme = (Cookies.get(CLIENT_THEME_COOKIE_KEY) as Theme) || Theme.System

  updateTheme(theme)
  return theme
}

Create a Theme Provider

// ./src/theme/Provider.tsx
import { PropsWithChildren, useState } from 'react'
import { Theme } from '../constants'
import { ThemeContext } from './context'
import { getDefaultTheme, updateTheme } from './lib'

type Props = PropsWithChildren & {
  defaultTheme?: Theme // Handle theme for SSR
}

export function ThemeProvider({ children, defaultTheme }: Props) {
  const [theme, setTheme] = useState<Theme>(defaultTheme || getDefaultTheme())

  const handleSetTheme = (theme: Theme) => {
    setTheme(theme)
    updateTheme(theme)
  }

  return <ThemeContext value={{ theme, setTheme: handleSetTheme }}>{children}</ThemeContext>
}

// ./src/theme/index.ts
export { ThemeProvider } from './Provider'
export { useThemeContext } from './context'

Use Theme Context in Components

// ./src/App.tsx
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import Card from './Card'
import { Theme } from './constants'
import { ThemeProvider } from './theme'

import './App.css'

// Theme from Server Entry
type AppProps = {
  theme?: Theme
}

function App({ theme }: AppProps) {
  return (
    <ThemeProvider defaultTheme={theme}>
      <div>
        <a href="https://vite.dev" target="_blank" rel="noreferrer">
          <img src={viteLogo} className="logo" alt="Vite logo" />
        </a>
        <a href="https://react.dev" target="_blank" rel="noreferrer">
          <img src={reactLogo} className="logo react" alt="React logo" />
        </a>
      </div>
      <h1>Vite + React</h1>
      <Card />
      <p className="read-the-docs">Click on the Vite and React logos to learn more</p>
    </ThemeProvider>
  )
}

export default App

Create a Card Component

// ./src/Card.tsx
import { useState } from 'react'
import { Theme } from './constants'
import { useThemeContext } from './theme'

function Card() {
  const { theme, setTheme } = useThemeContext()
  const [count, setCount] = useState(0)

  return (
    <div className='card'>
      <button onClick={() => setCount((count) => count + 1)}>count is {count}</button>
      <p>
        Edit <code>src/App.tsx</code> and save to test HMR
      </p>
      <div>
        Themes:{' '}
        <select value={theme} onChange={(event) => setTheme(event.target.value as Theme)}>
          <option value={Theme.System}>System</option>
          <option value={Theme.Light}>Light</option>
          <option value={Theme.Dark}>Dark</option>
        </select>
      </div>
    </div>
  )
}

export default Card

Resolve Hydration Error

Pass the theme to the server render method to ensure the server-generated HTML matches the client-side rendering:

import { renderToString } from 'react-dom/server'
import App from './App'
import { Theme } from './constants'

export function render(theme: Theme) {
  return renderToString(<App theme={theme} />)
}

Add Styles

:root {
    color: #242424;
    background-color: rgba(255, 255, 255, 0.87);
}

:root.dark {
    color: rgba(255, 255, 255, 0.87);
    background-color: #242424;
}

Conclusion

In this article, we tackled the challenges of implementing seamless theming in SSR React applications. By using cookies and integrating both client-side and server-side logic, we created a robust system that supports light, dark and system-based themes without hydration errors or user experience disruptions.

Explore the Code

Example: react-ssr-themes-example
Landing with SSR: professional-landing

This is part of my series on SSR with React. Stay tuned for more articles!

Building Production-Ready SSR React Applications
Advanced React SSR Techniques with Streaming and Dynamic Data
Setting Up Themes in SSR React Applications
Top Tools for React Server-Side Rendering Applications

Stay Connected

I’m always open to feedback, collaboration or discussing tech ideas — feel free to reach out!

linkedin/maksimriazantsev

Advanced React SSR Techniques with Streaming and Dynamic Data

Max — Sat, 04 Jan 2025 00:41:25 +0000

As your application grows, so do the challenges. To stay ahead, mastering advanced SSR techniques is essential for delivering a seamless and high-performance user experience.

Having built a foundation for server-side rendering in React projects in the previous article, I am excited to share features that can help you maintain project scalability, efficiently load data from the server to the client and resolve hydration issues.

What is Streaming in SSR
Lazy Loading and SSR
Implementing Streaming with Lazy Loading
- Updating React Components
- Updating the Server for Streaming
Server to Client Data
- Passing Data on the Server
- Handle Environment Variables on the Client
Hydration Issues
- Example Scenario
- Fixing Hydration Issues
Conclusion

What is Streaming in SSR

Streaming in server-side rendering (SSR) is a technique where the server sends parts of the HTML page to the browser in chunks as they are generated, rather than waiting for the entire page to be ready before delivering it. This allows the browser to start rendering content immediately, improving load times and the user's performance.

Streaming is particularly effective for:

Large Pages: Where generating the entire HTML could take significant time.
Dynamic Content: When parts of the page depend on external API calls or dynamically generated chunks.
High-Traffic Applications: To reduce server load and latency during peak usage.

Streaming bridges the gap between traditional SSR and modern client-side interactivity, ensuring users see meaningful content faster without compromising on performance.

Lazy Loading and SSR

Lazy loading is a technique that defers the loading of components or modules until they are actually needed, reducing the initial load time and improving performance. When combined with SSR, lazy loading can significantly optimize both server and client workloads.

Lazy loading relies on React.lazy, which dynamically imports components as Promises. In traditional SSR, rendering is synchronous, meaning the server must resolve all Promises before generating and sending the complete HTML to the browser.

Streaming resolves these challenges by allowing the server to send HTML in chunks as components are rendered. This approach enables the Suspense fallback to be sent to the browser immediately, ensuring users see meaningful content early. As lazy-loaded components are resolved, their rendered HTML is streamed incrementally to the browser, seamlessly replacing the fallback content. This avoids blocking the rendering process, reduces delays and improves perceived load times.

Implementing Streaming with Lazy Loading

This guide builds upon concepts introduced in the previous article, Building Production-Ready SSR React Applications, which you can find linked at the bottom. To enable SSR with React and support lazy-loaded components, we’ll make several updates to both the React components and the server.

Updating React Components

Server Entry Point

React’s renderToString method is commonly used for SSR, but it waits until the entire HTML content is ready before sending it to the browser. By switching to renderToPipeableStream, we can enable streaming, which sends parts of the HTML as they are generated.

// ./src/entry-server.tsx
import { renderToPipeableStream, RenderToPipeableStreamOptions } from 'react-dom/server'
import App from './App'

export function render(options?: RenderToPipeableStreamOptions) {
  return renderToPipeableStream(<App />, options)
}

Creating Lazy-Loaded Component

In this example, we’ll create a simple Card component to demonstrate the concept. In production applications, this technique is typically used with larger modules or entire pages to optimize performance.

// ./src/Card.tsx
import { useState } from 'react'

function Card() {
  const [count, setCount] = useState(0)

  return (
    <div className="card">
      <button onClick={() => setCount((count) => count + 1)}>
        count is {count}
      </button>
      <p>
        Edit <code>src/App.tsx</code> and save to test HMR
      </p>
    </div>
  )
}

export default Card

Using the Lazy-Loaded Component in the App

To use the lazy-loaded component, import it dynamically using React.lazy and wrap it with Suspense to provide a fallback UI during loading

// ./src/App.tsx
import { lazy, Suspense } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'

const Card = lazy(() => import('./Card'))

function App() {
  return (
    <>
      <div>
        <a href="https://vite.dev" target="_blank">
          <img src={viteLogo} className="logo" alt="Vite logo" />
        </a>
        <a href="https://react.dev" target="_blank">
          <img src={reactLogo} className="logo react" alt="React logo" />
        </a>
      </div>
      <h1>Vite + React</h1>
      <Suspense fallback='Loading...'>
        <Card />
      </Suspense>
      <p className="read-the-docs">
        Click on the Vite and React logos to learn more
      </p>
    </>
  )
}

export default App

Updating the Server for Streaming

To enable streaming, both the development and production setups need to support a consistent HTML rendering process. Since the process is the same for both environments, you can create a single reusable function to handle streaming content effectively.

Creating a Stream Content Function

// ./server/constants.ts
export const ABORT_DELAY = 5000

The streamContent function initiates the rendering process, writes incremental chunks of HTML to the response, and ensures proper error handling.

// ./server/streamContent.ts
import { Transform } from 'node:stream'
import { Request, Response, NextFunction } from 'express'
import { ABORT_DELAY, HTML_KEY } from './constants'
import type { render } from '../src/entry-server'

export type StreamContentArgs = {
  render: typeof render
  html: string
  req: Request
  res: Response
  next: NextFunction
}

export function streamContent({ render, html, res }: StreamContentArgs) {
  let renderFailed = false

  // Initiates the streaming process by calling the render function
  const { pipe, abort } = render({
    // Handles errors that occur before the shell is ready
    onShellError() {
      res.status(500).set({ 'Content-Type': 'text/html' }).send('<pre>Something went wrong</pre>')
    },
    // Called when the shell (initial HTML) is ready for streaming
    onShellReady() {
      res.status(renderFailed ? 500 : 200).set({ 'Content-Type': 'text/html' })

      // Split the HTML into two parts using the placeholder
      const [htmlStart, htmlEnd] = html.split(HTML_KEY)
      // Write the starting part of the HTML to the response
      res.write(htmlStart)

      // Create a transform stream to handle the chunks of HTML from the renderer
      const transformStream = new Transform({
        transform(chunk, encoding, callback) {
          // Write each chunk to the response
          res.write(chunk, encoding)
          callback()
        },
      })

      // When the streaming is finished, write the closing part of the HTML
      transformStream.on('finish', () => {
        res.end(htmlEnd)
      })

      // Pipe the render output through the transform stream
      pipe(transformStream)
    },
    onError(error) {
      // Logs errors encountered during rendering
      renderFailed = true
      console.error((error as Error).stack)
    },
  })

  // Abort the rendering process after a delay to avoid hanging requests
  setTimeout(abort, ABORT_DELAY)
}

Updating Development Configuration

// ./server/dev.ts
import { Application } from 'express'
import fs from 'fs'
import path from 'path'
import { StreamContentArgs } from './streamContent'

const HTML_PATH = path.resolve(process.cwd(), 'index.html')
const ENTRY_SERVER_PATH = path.resolve(process.cwd(), 'src/entry-server.tsx')

// Add to args the streamContent callback
export async function setupDev(app: Application, streamContent: (args: StreamContentArgs) => void) {
  const vite = await (
    await import('vite')
  ).createServer({
    root: process.cwd(),
    server: { middlewareMode: true },
    appType: 'custom',
  })

  app.use(vite.middlewares)

  app.get('*', async (req, res, next) => {
    try {
      let html = fs.readFileSync(HTML_PATH, 'utf-8')
      html = await vite.transformIndexHtml(req.originalUrl, html)

      const { render } = await vite.ssrLoadModule(ENTRY_SERVER_PATH)

      // Use the same callback for production and development process
      streamContent({ render, html, req, res, next })
    } catch (e) {
      vite.ssrFixStacktrace(e as Error)
      console.error((e as Error).stack)
      next(e)
    }
  })
}

Updating Production Configuration

// ./server/prod.ts
import { Application } from 'express'
import fs from 'fs'
import path from 'path'
import compression from 'compression'
import sirv from 'sirv'
import { StreamContentArgs } from './streamContent'

const CLIENT_PATH = path.resolve(process.cwd(), 'dist/client')
const HTML_PATH = path.resolve(process.cwd(), 'dist/client/index.html')
const ENTRY_SERVER_PATH = path.resolve(process.cwd(), 'dist/ssr/entry-server.js')

// Add to Args the streamContent callback
export async function setupProd(app: Application, streamContent: (args: StreamContentArgs) => void) {
  app.use(compression())
  app.use(sirv(CLIENT_PATH, { extensions: [] }))

  app.get('*', async (req, res, next) => {
    try {
      const html = fs.readFileSync(HTML_PATH, 'utf-8')

      const { render } = await import(ENTRY_SERVER_PATH)

      // Use the same callback for production and development process
      streamContent({ render, html, req, res, next })
    } catch (e) {
      console.error((e as Error).stack)
      next(e)
    }
  })
}

Updating the Express Server

Pass the streamContent function to each configuration:

// ./server/app.ts
import express from 'express'
import { PROD, APP_PORT } from './constants'
import { setupProd } from './prod'
import { setupDev } from './dev'
import { streamContent } from './streamContent'

export async function createServer() {
  const app = express()

  if (PROD) {
    await setupProd(app, streamContent)
  } else {
    await setupDev(app, streamContent)
  }

  app.listen(APP_PORT, () => {
    console.log(`http://localhost:${APP_PORT}`)
  })
}

createServer()

After implementing these changes, your server will:

Stream HTML to the browser incrementally, reducing time to first paint.
Seamlessly handle lazy-loaded components, improving both performance and user experience.

Server to Client Data

Before sending HTML to the client, you have full control over the server-generated HTML. This allows you to dynamically modify the structure by adding tags, styles, links or any other elements as needed.

One particularly powerful technique is injecting a <script> tag into the HTML. This approach enables you to pass dynamic data directly to the client.

In this example, we’ll focus on passing an environment variable, but you can pass any JavaScript object you need. By passing environment variables to the client, you avoid rebuilding the entire application when those variables change. In the example repository linked at the bottom, you can also see how profile data is passed dynamically.

Passing Data on the Server

Define API_URL

Set an API_URL environment variable on the server. By default, this will point to jsonplaceholder. The __INITIAL_DATA__ will act as the key for storing data on the global window object.

// ./server/constants.ts
export const API_URL = process.env.API_URL || 'https://jsonplaceholder.typicode.com'
export const WINDOW_INITIAL_DATA_KEY = '__INITIAL_DATA__'

Inject Initial Data into HTML

Create a utility function to inject the initial data into the HTML string before sending it to the client. This data will include environment variables like API_URL.

// ./server/lib/applyInitialData.ts
import { HTML_KEY, WINDOW_INITIAL_DATA_KEY } from '../constants'
import { InitialData } from '../streamContent'

type Args = {
  html: string
  initialData: InitialData
}

export function applyInitialData({ html, initialData }: Args): string {
  return html.replace(
    HTML_KEY,
    `<script>window.${WINDOW_INITIAL_DATA_KEY} = ${JSON.stringify(initialData)}</script>${HTML_KEY}`,
  )
}

Update streamContent

Use the applyInitialData function to inject the initial data into the HTML and send it to the client.

// ./server/streamContent.ts
import { Transform } from 'node:stream'
import { Request, Response, NextFunction } from 'express'
import { ABORT_DELAY, API_URL, HTML_KEY } from './constants'
import { applyInitialData } from './lib/applyInitialData'
import type { render } from '../src/entry-server'

export type InitialData = {
  env: {
    API_URL: string
  }
}

export type StreamContentArgs = {
  render: typeof render
  html: string
  req: Request
  res: Response
  next: NextFunction
}

export function streamContent({ render, html, res }: StreamContentArgs) {
  html = applyInitialData({ html, initialData: { env: { API_URL } } })

  let renderFailed = false

  const { pipe, abort } = render()

  setTimeout(abort, ABORT_DELAY)
}

Handle Environment Variables on the Client

Extend the Global `window` Type

Update the global type declaration to include the __INITIAL_DATA__ key and its structure.

// ./src/global.d.ts
import { WINDOW_INITIAL_DATA_KEY } from './constants'
import type { InitialData } from '../server/streamContent'

export {}

declare global {
  interface Window {
    [WINDOW_INITIAL_DATA_KEY]?: InitialData
  }
}

Access API_URL from the Window Object

// ./src/constants.ts
export const WINDOW_INITIAL_DATA_KEY = '__INITIAL_DATA__'
export const SSR = import.meta.env.SSR

export const INITIAL_DATA = !SSR && window[WINDOW_INITIAL_DATA_KEY] ? window[WINDOW_INITIAL_DATA_KEY] : undefined
export const API_URL = INITIAL_DATA?.env.API_URL || ''

Make a Request Using the Dynamic API_URL

// ./src/App.tsx
import { lazy, Suspense, useEffect } from 'react'
import reactLogo from './assets/react.svg'
import { API_URL } from './constants'
import viteLogo from '/vite.svg'

import './App.css'

const Card = lazy(() => import('./Card'))

function App() {
  useEffect(() => {
    ;(async () => {
      const response = await fetch(`${API_URL}/posts`)
      const data = await response.json()

      console.log(data)
    })()
  }, [])

  return <>{/* ... */}</>
}

export default App

Now you have a dynamic environment variable available in your client-side code, enabling you to manage server-to-client data without the need to rebuild the JavaScript bundle. This approach simplifies configuration and makes your app more flexible and scalable.

Hydration Issues

Now that you can pass data from the server to the client, you might encounter hydration issues if you try to use this data directly inside a component. These errors occur because the server-rendered HTML doesn’t match the initial React render on the client.

Example Scenario

Consider using API_URL as a simple string in your component

// ./src/App.tsx
import { API_URL } from './constants'

function App() {
  return <p>API_URL: {API_URL}</p>
}

In this case, the server will render the component with API_URL as an empty string, but on the client, API_URL will already have a value from the window object. This mismatch causes a hydration error because React detects a difference between the server-rendered HTML and the client’s React tree.

While the user may see the content update quickly, React logs a hydration warning in the console. To fix this issue, you need to ensure that the server and client render the same initial HTML or pass API_URL explicitly to the server entry point.

Fixing Hydration Issues

To resolve error, pass initialData to the App component via the server entry point.

Update `streamContent`

// ./server/streamContent.ts
const initialData: InitialData = { env: { API_URL } }

export function streamContent({ render, html, res }: StreamContentArgs) {
  html = applyInitialData({ html, initialData })

  let renderFailed = false

  // Pass as first argument to the render function
  const { pipe, abort } = render(initialData, {})

  setTimeout(abort, ABORT_DELAY)
}

Handle Data in the `render` Function

// ./src/entry-server.tsx
import { renderToPipeableStream, RenderToPipeableStreamOptions } from 'react-dom/server'
import App from './App'
import type { InitialData } from '../server/streamContent'

export function render(initialData: InitialData, options?: RenderToPipeableStreamOptions) {
  return renderToPipeableStream(<App initialData={initialData} />, options)
}

Use `initialData` in the App Component

// ./src/App.tsx
import { API_URL, SSR } from './constants'
import type { InitialData } from '../server/streamContent'

type AppProps = {
  initialData?: InitialData
}

function App({ initialData }: AppProps) {
  return <p>API_URL: {SSR ? initialData?.env.API_URL : API_URL}</p>
}

Now, your server-rendered HTML will match the initial React render on the client, eliminating hydration errors. React will correctly reconcile the server and client trees, ensuring a seamless experience.

For dynamic data like API_URL, consider using React Context to manage and pass default values between the server and client. This approach simplifies managing shared data across components. You can find an example implementation in the linked repository at the bottom.

Conclusion

In this article, we explored advanced SSR techniques for React, focusing on implementing streaming, managing server-to-client data and resolving hydration issues. These methods ensure your application is scalable, high-performing and create seamless user experiences.

Explore the Code

Example: react-ssr-advanced-example
Template: react-ssr-streaming-template
Vite Extra Template: template-ssr-react-streaming-ts

This is part of my series on SSR with React. Stay tuned for more articles!

Building Production-Ready SSR React Applications
Advanced React SSR Techniques with Streaming and Dynamic Data
Setting Up Themes in SSR React Applications
Top Tools for React Server-Side Rendering Applications

Stay Connected

I’m always open to feedback, collaboration or discussing tech ideas — feel free to reach out!

linkedin/maksimriazantsev

Building Production-Ready SSR React Applications

Max — Thu, 02 Jan 2025 16:04:55 +0000

In a world where every millisecond matters, server-side rendering has become an essential capability for frontend applications.

This guide will walk you through the fundamental patterns for building a production-ready SSR with React. You'll gain an understanding of the principles behind React-based frameworks with built-in SSR (like Next.js) and learn how to create your own custom solutions.

The provided code is production-ready, featuring a complete build process for both client and server parts, including a Dockerfile. In this implementation, Vite is used to build the client and SSR code, but you can use any other tools of your choice. Vite is also give hot-reloading during development mode for the client.

If you're interested in a version of this setup without Vite, feel free to reach out.

What is SSR
Creating the App
- Initializing Vite
- Updating React Components
- Create Server
- Configuring the Build
Routing
Docker
Conclusion

What is SSR

Key benefits of SSR:

Improved SEO: Since search engine crawlers receive fully-rendered content, SSR ensures better indexing and ranking.
Faster First Paint: Users see meaningful content almost immediately, as the server handles the heavy lifting of rendering.
Enhanced Performance: By reducing the rendering workload on the browser, SSR provides a smoother experience for users on older or less powerful devices.
Seamless Server-to-Client Data Transfer: SSR allows you to pass dynamic server-side data to the client without rebuilding the client bundle.

Creating The App

The flow of your app with SSR follows these steps:

Read the template HTML file.
Initialize React and generate an HTML string of the app's content.
Inject the generated HTML string into the template.
Send the complete HTML to the browser.
On the client, match the HTML tags and hydrate the application, making it interactive.

Initializing Vite

I prefer to use pnpm and react-swc-ts Vite template, but you can choose any other setup.

pnpm create vite react-ssr-app --template react-swc-ts

Install the dependencies:

pnpm install

Updating React Components

In a typical React application, there’s a single main.tsx entry point for index.html. With SSR, you need two entry points: one for the server and one for the client.

Server Entry Point

The Node.js server will run your app and generate the HTML by rendering your React components to a string (renderToString).

// ./src/entry-server.tsx
import { renderToString } from 'react-dom/server'
import App from './App'

export function render() {
  return renderToString(<App />)
}

Client Entry Point

The browser will hydrate the server-generated HTML, connecting it with the JavaScript to make the page interactive.

Hydration is the process of attaching event listeners and other dynamic behaviors to the static HTML rendered by the server.

// ./src/entry-client.tsx
import { hydrateRoot } from 'react-dom/client'
import { StrictMode } from 'react'
import App from './App'

import './index.css'

hydrateRoot(
  document.getElementById('root')!,
  <StrictMode>
    <App />
  </StrictMode>,
)

Updating `index.html`

Update the index.html file in the root of your project. The  placeholder is where the server will inject the generated HTML.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite + React + TS</title>
  </head>
  <body>
    <div id="root"><!--app-html--></div>
    <script type="module" src="/src/entry-client.tsx"></script>
  </body>
</html>

Create Server

First, install the dependencies:

pnpm install -D express compression sirv tsup vite-node nodemon @types/express @types/compression

All dependencies required for the server should be installed as development dependencies (devDependencies) to ensure they are not included in the client bundle.

Next, create a folder in the root of your project named ./server and add the following files.

Re-exporting the Main Server File

Re-export the main server file. This makes running commands more convenient.

// ./server/index.ts
export * from './app'

Defining Constants

The HTML_KEY constant must match the placeholder comment in index.html. Other constants manage environment settings.

// ./server/constants.ts
export const NODE_ENV = process.env.NODE_ENV || 'development'
export const APP_PORT = process.env.APP_PORT || 3000

export const PROD = NODE_ENV === 'production'
export const HTML_KEY = `<!--app-html-->`

Creating the Express Server

Set up an Express server with different configurations for development and production environments.

// ./server/app.ts
import express from 'express'
import { PROD, APP_PORT } from './constants'
import { setupProd } from './prod'
import { setupDev } from './dev'

export async function createServer() {
  const app = express()

  if (PROD) {
    await setupProd(app)
  } else {
    await setupDev(app)
  }

  app.listen(APP_PORT, () => {
    console.log(`http://localhost:${APP_PORT}`)
  })
}

createServer()

Development Mode Configuration

In development, use Vite’s middleware to handle requests and dynamically transform the index.html file with hot reload. The server will load the React application and render it to HTML on each request.

// ./server/dev.ts
import { Application } from 'express'
import fs from 'fs'
import path from 'path'
import { HTML_KEY } from './constants'

const HTML_PATH = path.resolve(process.cwd(), 'index.html')
const ENTRY_SERVER_PATH = path.resolve(process.cwd(), 'src/entry-server.tsx')

export async function setupDev(app: Application) {
  // Create a Vite development server in middleware mode
  const vite = await (
    await import('vite')
  ).createServer({
    root: process.cwd(),
    server: { middlewareMode: true },
    appType: 'custom',
  })

  // Use Vite middleware for serving files
  app.use(vite.middlewares)

  app.get('*', async (req, res, next) => {
    try {
      // Read and transform the HTML file
      let html = fs.readFileSync(HTML_PATH, 'utf-8')
      html = await vite.transformIndexHtml(req.originalUrl, html)

      // Load the entry-server.tsx module and render the app
      const { render } = await vite.ssrLoadModule(ENTRY_SERVER_PATH)
      const appHtml = await render()

      // Replace the placeholder with the rendered HTML
      html = html.replace(HTML_KEY, appHtml)
      res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
    } catch (e) {
      // Fix stack traces for Vite and handle errors
      vite.ssrFixStacktrace(e as Error)
      console.error((e as Error).stack)
      next(e)
    }
  })
}

Production Mode Configuration

In production, use compression to optimize performance, sirv to serve static files and the pre-built server bundle to render the app.

// ./server/prod.ts
import { Application } from 'express'
import fs from 'fs'
import path from 'path'
import compression from 'compression'
import sirv from 'sirv'
import { HTML_KEY } from './constants'

const CLIENT_PATH = path.resolve(process.cwd(), 'dist/client')
const HTML_PATH = path.resolve(process.cwd(), 'dist/client/index.html')
const ENTRY_SERVER_PATH = path.resolve(process.cwd(), 'dist/ssr/entry-server.js')

export async function setupProd(app: Application) {
  // Use compression for responses
  app.use(compression())
  // Serve static files from the client build folder
  app.use(sirv(CLIENT_PATH, { extensions: [] }))

  app.get('*', async (_, res, next) => {
    try {
      // Read the pre-built HTML file
      let html = fs.readFileSync(HTML_PATH, 'utf-8')

      // Import the server-side render function and generate HTML
      const { render } = await import(ENTRY_SERVER_PATH)
      const appHtml = await render()

      // Replace the placeholder with the rendered HTML
      html = html.replace(HTML_KEY, appHtml)
      res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
    } catch (e) {
      // Log errors and pass them to the error handler
      console.error((e as Error).stack)
      next(e)
    }
  })
}

Configuring the Build

To follow best practices for building your application, you should exclude all unnecessary packages and include only what your application actually uses.

Updating Vite Configuration

Update your Vite configuration to optimize the build process and handle SSR dependencies:

// ./vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react-swc'
import { dependencies } from './package.json'

export default defineConfig(({ mode }) => ({
  plugins: [react()],
  ssr: {
    noExternal: mode === 'production' ? Object.keys(dependencies) : undefined,
  },
}))

Updating `tsconfig.json`

Update your tsconfig.json to include the server files and configure TypeScript appropriately:

{
  "include": [
    "src",
    "server",
    "vite.config.ts"
  ]
}

Creating `tsup` Configuration

Use tsup, a TypeScript bundler, to build the server code. The noExternal option specifies the packages to bundle with the server. Be sure to include any additional packages your server uses.

// ./tsup.config.ts
import { defineConfig } from 'tsup'

export default defineConfig({
  entry: ['server'],
  outDir: 'dist/server',
  target: 'node22',
  format: ['cjs'],
  clean: true,
  minify: true,
  external: ['lightningcss', 'esbuild', 'vite'],
  noExternal: ['express', 'sirv', 'compression'],
})

Adding Build Scripts

{
  "scripts": {
    "dev": "nodemon --exec vite-node server --watch server --ext ts",
    "start": "NODE_ENV=production node dist/server/index.cjs",
    "build": "tsc -b && npm run build:client && npm run build:ssr && npm run build:server",
    "build:client": "vite build --outDir dist/client",
    "build:ssr": "vite build --outDir dist/ssr --ssr src/entry-server.tsx",
    "build:server": "tsup"
  }
}

Running the Application

Development: Use the following command to start the application with hot reloading:

pnpm dev

Production: Build the application and start the production server:

pnpm build && pnpm start

To verify that SSR is working, check the first network request to your server. The response should contain the fully-rendered HTML of your application.

Routing

To add different pages to your app, you need to configure routing properly and handle it in both client and server entry points.

pnpm install react-router

Adding Client-Side Routing

Wrap your application with BrowserRouter in the client entry point to enable client-side routing.

// ./src/entry-client.tsx
import { hydrateRoot } from 'react-dom/client'
import { StrictMode } from 'react'
import { BrowserRouter } from 'react-router'
import App from './App'

import './index.css'

hydrateRoot(
  document.getElementById('root')!,
  <StrictMode>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </StrictMode>,
)

Adding Server-Side Routing

Use StaticRouter in the server entry point to handle server-side routing. Pass the url as a prop to render the correct route based on the request.

import { renderToString } from 'react-dom/server'
import { StaticRouter } from 'react-router'
import App from './App'

export function render(url: string) {
  return renderToString(
    <StaticRouter location={url}>
      <App />
    </StaticRouter>,
  )
}

Updating Server Configurations

Update both your development and production server setups to pass the request URL to the render function:

// ./server/dev.ts
// ./server/prod.ts
const appHtml = await render(req.url)

// Replace the placeholder with the rendered HTML
html = html.replace(HTML_KEY, appHtml)
res.status(200).set({ 'Content-Type': 'text/html' }).end(html)
//...

With these changes, you can now create routes in your React app that are fully compatible with SSR. However, this basic approach does not handle lazy-loaded components (React.lazy). For managing lazy-loaded modules, please refer to my other article, Advanced React SSR Techniques with Streaming and Dynamic Data, linked at the bottom.

Docker

Here’s a Dockerfile to containerize your application:

# Build App
FROM node:22-alpine as builder

WORKDIR /app
COPY . .

RUN corepack enable && pnpm install && pnpm build

# Production
FROM node:22-alpine

WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./package.json

EXPOSE 3000

CMD ["npm", "run", "start"]

Building and Running the Docker Image

docker build -t react-ssr-app .

docker run -p 3000:3000 react-ssr-app

Conclusion

In this guide, we’ve established a strong foundation for creating production-ready SSR applications with React. You’ve learned how to set up the project, configure routing and create a Dockerfile. This setup is ideal for building landing pages or small app efficiently.

Explore the Code

Example: react-ssr-basics-example
Template: react-ssr-template
Vite Extra Template: template-ssr-react-ts

This is part of my series on SSR with React. Stay tuned for more articles!

Building Production-Ready SSR React Applications
Advanced React SSR Techniques with Streaming and Dynamic Data
Setting Up Themes in SSR React Applications
Top Tools for React Server-Side Rendering Applications

Stay Connected

I’m always open to feedback, collaboration or discussing tech ideas — feel free to reach out!

linkedin/maksimriazantsev

Forem: Max

Top Tools for React Server-Side Rendering Applications

Top Tools for React Server-Side Rendering Applications

Table of Contents

What is SSR

Key benefits

Challenges

When to Use SSR

Ideal Scenarios

Limitations

Is SSR the Right Choice?

Tools

Next.js

Remix

Vike (Vite Plugin SSR)

Custom SSR

Server Components

Comparison Table

Conclusion

Related Articles

Stay Connected

Setting Up Themes in SSR React Applications

Table of Contents

Themes and SSR

Implementation

Install Dependencies

Add cookie to the Server Build

Apply Themes on the Server

Define Theme Constants

Apply Theme Class to Tag

Retrieve the Client Theme Cookie

Update Server Configurations for Theming

Handle Themes on the Client

Define Constants

Create Theme Context

Implement Theme Utilities

Create a Theme Provider

Use Theme Context in Components

Create a Card Component

Resolve Hydration Error

Add Styles

Conclusion

Explore the Code

Related Articles

Stay Connected

Advanced React SSR Techniques with Streaming and Dynamic Data

Table of Contents

What is Streaming in SSR

Lazy Loading and SSR

Implementing Streaming with Lazy Loading

Updating React Components

Server Entry Point

Creating Lazy-Loaded Component

Using the Lazy-Loaded Component in the App

Updating the Server for Streaming

Creating a Stream Content Function

Updating Development Configuration

Updating Production Configuration

Updating the Express Server

Server to Client Data

Passing Data on the Server

Define API_URL

Inject Initial Data into HTML

Update streamContent

Handle Environment Variables on the Client

Extend the Global window Type

Access API_URL from the Window Object

Make a Request Using the Dynamic API_URL

Hydration Issues

Example Scenario

Fixing Hydration Issues

Update streamContent

Handle Data in the render Function

Use initialData in the App Component

Conclusion

Explore the Code

Related Articles

Stay Connected

Building Production-Ready SSR React Applications

Table of Contents

Extend the Global `window` Type

Update `streamContent`

Handle Data in the `render` Function

Use `initialData` in the App Component

Updating `index.html`

Updating `tsconfig.json`

Creating `tsup` Configuration