DOCSEARCHbyAlgolia
Submit Docs

@lazarv/react-server

website·Indexed 32 days ago

https://react-server.dev

A runtime for building React applications with server-side rendering using React Server Components (RSC). It features a fully typed router with compile-time type safety, built-in support for Server Functions, Partial Pre-rendering (PPR), and Hydration Islands. The runtime is built on top of the Vite Environment API and includes a dedicated CLI for development and deployment via built-in adapters.

Tokens
101.4K
Snippets
534
Records
688
Agent score
65%

What's inside react-server

  1. Overview of Hydration Islands

    Hydration islands allow a mostly static server-rendered page to hydrate only selected subtrees. By marking a component with the "use hydrate" directive, the runtime renders the subtree as normal server HTML and writes a separate RSC payload for the island, which is then hydrated as a local non-root outlet. Unlike standard "use client" components, hydration islands do not require the page root to be hydrated or have a PAGE_ROOT RSC payload. If a component marked with "use hydrate" is rendered later via an RSC update payload, it behaves as a normal component because it is already part of the existing React tree.

  2. Overview of @lazarv/react-server core concepts

    @lazarv/react-server is built around three main pillars of React server-side rendering: React Server Components (RSC), interactive Client Components, and Server Functions for server-side interaction.

  3. Overview of @lazarv/react-server features and capabilities

    @lazarv/react-server is a full React Server Components (RSC) runtime and routing system integrated with the Vite build pipeline. Unlike traditional routers, it is built from the ground up for RSC, allowing every route to mix server and client components freely. Key capabilities include:

    • Full-stack Features: Built-in support for RSC, Server Functions (actions) with an encrypted reference and hardened decoder defense layer, SSR/Streaming SSR, API routes, Static Site Generation, Partial Pre-rendering (PPR), and Response Caching (TTL).
    • Architecture: An open runtime (no vendor lock-in) based on Vite, featuring a production HTTP layer with backpressure and security, OTel traces/metrics for observability, Hydration Islands, and support for Micro-frontends/Remote Components and MCP Server Integration.
    • Routing: Supports both code-based and file-based routing, virtual/programmatic routes, ranked route matching, and client-only routes. It includes navigation guards/blockers and parallel routes/outlets.
    • Type Safety: Provides end-to-end type safety for route paths, path parameters, navigation, and search parameters. It supports multi-library schema validation (Zod, ArkType, Valibot) and auto-generated route types for file-routers.
    • Search Params: Features typed search parameters with schema validation, functional updaters (prev => next), and route-scoped search transforms.
    • Scroll Restoration: Includes zero-flash restoration via a pre-hydration script, element/container scroll restoration, and prefers-reduced-motion awareness.
    • Data Fetching: Implements typed resource descriptors, schema-validated resource keys, and a Suspense-integrated .use() hook, alongside SWR caching via "use cache".

  4. Overview of @lazarv/react-server Routing

    The @lazarv/react-server runtime provides a fully typed routing system that ensures compile-time type safety for routes, links, parameters, and search parameters. It supports server-rendered routes, client-only routes, and shared routes. Developers can define routes using createRoute and createRouter to enable typed Link components, typed hooks, schema validation, and IDE autocompletion across both server and client environments.

  5. Overview of Model Context Protocol (MCP) in @lazarv/react-server

    MCP is an experimental feature in @lazarv/react-server that provides a structured, declarative way to expose server-side functions, tools, and resources to language models (LLMs) and automated agents. Unlike standard Server Functions, MCP handlers are self-describing units with defined IDs, titles, input schemas, and invocation templates, making them discoverable and type-safe for AI toolchains.

  6. Overview of Lexically Scoped React Server Components

    Standard React Server Components (RSC) require "use client" and "use server" directives to be at the module level, forcing developers to split logic into multiple files. Lexically Scoped RSCs, implemented via @lazarv/react-server, allow these directives to appear inside individual function bodies at any nesting depth. This enables 'island composition' within a single file, where server and client logic can be interleaved without artificial file boundaries.

  7. Overview of @lazarv/rsc for Bundler-Agnostic RSC Serialization

    @lazarv/rsc is a from-scratch implementation of React's Flight protocol. It is designed to remove three primary couplings found in the official react-server-dom-webpack implementation:

    1. Bundler Coupling: It does not require Webpack manifests or specific plugins; module resolution is handled via an abstract interface provided by the consumer.
    2. Environment Coupling: It uses only Web Platform APIs (ReadableStream, TextEncoder, TextDecoder, FormData, Blob, URL), making it compatible with Node.js, Deno, Bun, Cloudflare Workers, and the browser without separate builds or polyfills.
    3. Export Condition Coupling: It does not require the react-server Node.js export condition, allowing it to be loaded in worker threads, custom runtimes, or embedded engines without special configuration.

    It maintains full wire-format parity with react-server-dom-webpack, supporting all standard RSC types including elements, fragments, Suspense, Promises, and various JavaScript built-ins (Map, Set, Date, etc.).

  8. Overview of @lazarv/react-server/telemetry

    The @lazarv/react-server/telemetry module provides OpenTelemetry integration. It is designed to be a safe no-op when OpenTelemetry packages are not installed, meaning you can import and use its functions (like getTracer, getMeter, and withSpan) directly without needing to guard them with conditional checks.

  9. Overview of @lazarv/react-server capabilities

    @lazarv/react-server is a runtime for building server-side rendered (SSR) React applications. It is built on top of Vite, allowing developers to use Vite configuration options and plugins. Key capabilities include a dedicated CLI for build/deploy workflows, server-side data caching (in-memory by default), and full HTTP context access during SSR, middlewares, route handlers, and server functions.

  10. Understand React Server Components basics

    React Server Components (RSC) are components rendered on the server and streamed to the client as HTML or a JSON serialized React component tree. A key performance benefit is that the source code of server components is not sent to the client, only the resulting output. Because they are stateless, you cannot use stateful React hooks (like useState or useEffect) within them. To manage state in server components, use query parameters or cookies.

  11. Use the @lazarv/react-server file-system based router

    The @lazarv/react-server package provides a file-system based router similar to Next.js. The router is automatically activated when no entrypoint is specified in the react-server CLI commands.

  12. Understand the architectural differences between Next.js and @lazarv/react-server

    @lazarv/react-server is a React Server Components (RSC) runtime built on Vite, whereas Next.js is a full-stack framework with its own compiler and proprietary next/* modules.

    Key shifts include:

    • Build System: Uses Vite Environment API and plugins instead of the Next compiler/Webpack/Turbopack.
    • API Surface: Does not implement next/* APIs (e.g., next/navigation, next/cache, next/image). Developers should use React, Web Platform APIs, and the runtime's own modules.
    • Routing: While Next.js uses a strict file-system App Router, @lazarv/react-server provides a file router combined with a code-based typed router.
    • Type Safety: Provides typed route descriptors, links, params, and search params with runtime validation.
    • Middleware: Uses segment-scoped *.middleware.* files and config handlers instead of a single project-level proxy.
    • APIs: Uses *.server.* API routes and method-prefixed route files instead of route.ts Route Handlers.