From d3087ab054d65cb69346436d28e17ce69edce79c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Viktor=20L=C3=A1z=C3=A1r?= Date: Mon, 2 Mar 2026 21:49:10 +0100 Subject: [PATCH 1/5] docs: move framework to features --- docs/messages/en.json | 2 +- docs/messages/ja.json | 2 +- docs/public/llms.txt | 212 ++++++ docs/src/pages.mjs | 2 +- docs/src/pages/(root).layout.jsx | 10 +- .../[[lang]]/(header).[[...slug]].page.jsx | 6 +- docs/src/pages/en/(pages)/deploy/bun.mdx | 2 +- docs/src/pages/en/(pages)/deploy/deno.mdx | 2 +- .../{framework => features}/caching.mdx | 2 +- .../(pages)/{framework => features}/cli.mdx | 2 +- .../{framework => features}/cluster.mdx | 2 +- .../{framework => features}/configuration.mdx | 16 +- .../error-handling.mdx | 2 +- .../(pages)/{framework => features}/http.mdx | 10 +- .../live-components.mdx | 14 +- .../(pages)/{framework => features}/mcp.mdx | 8 +- .../micro-frontends.mdx | 4 +- .../middleware-mode.mdx | 2 +- .../(pages)/{framework => features}/ppr.mdx | 6 +- .../server-function-encryption.mdx | 12 +- .../{framework => features}/worker.mdx | 18 +- .../en/(pages)/guide/design-decisions.mdx | 44 +- .../pages/en/(pages)/guide/get-started.mdx | 10 +- .../pages/en/(pages)/guide/quick-start.mdx | 4 +- .../en/(pages)/guide/server-functions.mdx | 2 +- .../pages/en/(pages)/integrations/mantine.mdx | 2 +- .../src/pages/en/(pages)/integrations/mui.mdx | 2 +- .../en/(pages)/integrations/typescript.mdx | 2 +- .../en/(pages)/router/client-navigation.mdx | 2 +- .../en/(pages)/router/error-handling.mdx | 2 +- .../pages/en/(pages)/router/file-router.mdx | 2 +- .../pages/en/(pages)/router/loading.page.mdx | 2 +- .../en/(pages)/router/server-routing.mdx | 4 +- .../en/(pages)/tutorials/hello-world.mdx | 4 +- .../src/pages/en/(pages)/tutorials/photos.mdx | 6 +- .../pages/en/(pages)/tutorials/todo-app.mdx | 4 +- docs/src/pages/en/deploy.(index).mdx | 2 +- docs/src/pages/en/features.(index).mdx | 19 + docs/src/pages/en/framework.(index).mdx | 19 - docs/src/pages/en/index.mdx | 16 +- docs/src/pages/en/integrations.(index).mdx | 4 +- docs/src/pages/en/router.(index).mdx | 4 +- docs/src/pages/ja/(pages)/deploy/bun.mdx | 2 +- .../{framework => features}/caching.mdx | 2 +- .../(pages)/{framework => features}/cli.mdx | 2 +- .../{framework => features}/cluster.mdx | 2 +- .../{framework => features}/configuration.mdx | 16 +- .../error-handling.mdx | 2 +- .../(pages)/{framework => features}/http.mdx | 6 +- .../micro-frontends.mdx | 4 +- .../middleware-mode.mdx | 2 +- .../(pages)/{framework => features}/ppr.mdx | 6 +- .../ja/(pages)/guide/design-decisions.mdx | 720 ++++++++++++++++++ .../pages/ja/(pages)/guide/get-started.mdx | 10 +- .../pages/ja/(pages)/guide/quick-start.mdx | 4 +- .../ja/(pages)/guide/server-functions.mdx | 2 +- docs/src/pages/ja/(pages)/guide/why.mdx | 160 ---- .../pages/ja/(pages)/integrations/mantine.mdx | 2 +- .../src/pages/ja/(pages)/integrations/mui.mdx | 2 +- .../ja/(pages)/integrations/typescript.mdx | 2 +- .../ja/(pages)/router/client-navigation.mdx | 2 +- .../ja/(pages)/router/error-handling.mdx | 2 +- .../pages/ja/(pages)/router/file-router.mdx | 4 +- .../pages/ja/(pages)/router/loading.page.mdx | 2 +- .../ja/(pages)/router/server-routing.mdx | 4 +- .../ja/(pages)/tutorials/hello-world.mdx | 4 +- .../src/pages/ja/(pages)/tutorials/photos.mdx | 6 +- .../pages/ja/(pages)/tutorials/todo-app.mdx | 4 +- docs/src/pages/ja/deploy.(index).mdx | 2 +- docs/src/pages/ja/features.(index).mdx | 17 + docs/src/pages/ja/framework.(index).mdx | 17 - docs/src/pages/ja/index.mdx | 16 +- docs/src/pages/ja/integrations.(index).mdx | 2 +- docs/src/pages/ja/router.(index).mdx | 4 +- packages/react-server/README.md | 2 +- packages/react-server/package.json | 2 +- 76 files changed, 1147 insertions(+), 381 deletions(-) create mode 100644 docs/public/llms.txt rename docs/src/pages/en/(pages)/{framework => features}/caching.mdx (99%) rename docs/src/pages/en/(pages)/{framework => features}/cli.mdx (99%) rename docs/src/pages/en/(pages)/{framework => features}/cluster.mdx (98%) rename docs/src/pages/en/(pages)/{framework => features}/configuration.mdx (85%) rename docs/src/pages/en/(pages)/{framework => features}/error-handling.mdx (99%) rename docs/src/pages/en/(pages)/{framework => features}/http.mdx (93%) rename docs/src/pages/en/(pages)/{framework => features}/live-components.mdx (65%) rename docs/src/pages/en/(pages)/{framework => features}/mcp.mdx (95%) rename docs/src/pages/en/(pages)/{framework => features}/micro-frontends.mdx (98%) rename docs/src/pages/en/(pages)/{framework => features}/middleware-mode.mdx (99%) rename docs/src/pages/en/(pages)/{framework => features}/ppr.mdx (88%) rename docs/src/pages/en/(pages)/{framework => features}/server-function-encryption.mdx (93%) rename docs/src/pages/en/(pages)/{framework => features}/worker.mdx (89%) create mode 100644 docs/src/pages/en/features.(index).mdx delete mode 100644 docs/src/pages/en/framework.(index).mdx rename docs/src/pages/ja/(pages)/{framework => features}/caching.mdx (99%) rename docs/src/pages/ja/(pages)/{framework => features}/cli.mdx (99%) rename docs/src/pages/ja/(pages)/{framework => features}/cluster.mdx (98%) rename docs/src/pages/ja/(pages)/{framework => features}/configuration.mdx (77%) rename docs/src/pages/ja/(pages)/{framework => features}/error-handling.mdx (99%) rename docs/src/pages/ja/(pages)/{framework => features}/http.mdx (96%) rename docs/src/pages/ja/(pages)/{framework => features}/micro-frontends.mdx (98%) rename docs/src/pages/ja/(pages)/{framework => features}/middleware-mode.mdx (99%) rename docs/src/pages/ja/(pages)/{framework => features}/ppr.mdx (82%) create mode 100644 docs/src/pages/ja/(pages)/guide/design-decisions.mdx delete mode 100644 docs/src/pages/ja/(pages)/guide/why.mdx create mode 100644 docs/src/pages/ja/features.(index).mdx delete mode 100644 docs/src/pages/ja/framework.(index).mdx diff --git a/docs/messages/en.json b/docs/messages/en.json index fd301fa8..3c4b91e6 100644 --- a/docs/messages/en.json +++ b/docs/messages/en.json @@ -2,7 +2,7 @@ "$schema": "https://inlang.com/schema/inlang-message-format", "category_guide": "Guide", "category_integrations": "Integrations", - "category_framework": "Framework", + "category_features": "Features", "category_router": "Router", "category_deploy": "Deploy", "category_tutorials": "Tutorials", diff --git a/docs/messages/ja.json b/docs/messages/ja.json index 2cbbc8ec..6252f48a 100644 --- a/docs/messages/ja.json +++ b/docs/messages/ja.json @@ -2,7 +2,7 @@ "$schema": "https://inlang.com/schema/inlang-message-format", "category_guide": "ガイド", "category_integrations": "統合", - "category_framework": "フレームワーク", + "category_features": "機能", "category_router": "ルーター", "category_deploy": "デプロイ", "category_tutorials": "チュートリアル", diff --git a/docs/public/llms.txt b/docs/public/llms.txt new file mode 100644 index 00000000..b513558f --- /dev/null +++ b/docs/public/llms.txt @@ -0,0 +1,212 @@ +# @lazarv/react-server + +> Run React anywhere + +@lazarv/react-server is a React runtime that renders React Server Components on the server with streaming SSR, supports client components, server functions, file-system routing, caching, static generation, partial pre-rendering, live components, workers, micro-frontends, and MCP server capabilities. It runs on Node.js, Bun, and Deno, and deploys to Vercel, Netlify, Cloudflare, AWS, Azure, Firebase, Docker, and more with built-in adapters. + +## Quick Start + +Install: + +```sh +pnpm add @lazarv/react-server +``` + +Create App.jsx: + +```jsx +export default function App() { + return

Hello World!

; +} +``` + +Run: + +```sh +pnpm react-server ./App.jsx +``` + +No config files, no boilerplate, no separate React installation needed. Or use the scaffolding tool: `npx @lazarv/create-react-server`. + +## Key Concepts + +- **React Server Components**: The default rendering model. Components render on the server, support async/await, and their source code never reaches the client. +- **Client Components**: Add `"use client"` directive to enable interactivity. Components are server-rendered then hydrated on the client. +- **Server Functions**: Add `"use server"` to turn async functions into server-side RPC endpoints. Works as form actions with progressive enhancement. +- **File-System Router**: Activates automatically when no entrypoint is specified. Supports pages, layouts, outlets, API routes, middlewares, error boundaries, and loading states. +- **Client Navigation**: SPA-like navigation with `Link`, `Form`, `Refresh`, and `ReactServerComponent` components. Supports prefetching, error rollback, and outlet-scoped rendering. +- **Caching**: Multi-layered caching with response cache, in-memory cache, `"use cache"` directive, and Unstorage-backed cache providers. +- **Partial Pre-Rendering (PPR)**: Mix static and dynamic content using `"use dynamic"` and `"use static"` directives. +- **Live Components**: Real-time server-to-client streaming with `"use live"` async generators over WebSocket. +- **Workers**: Offload computation with `"use worker"` — Node.js Worker Threads on server, Web Workers on client, with HMR support. +- **Micro-Frontends**: Compose remote RSC applications with `RemoteComponent`, supporting streaming and shadow DOM isolation. +- **MCP Server**: Build Model Context Protocol servers with tools, resources, and prompts as HTTP endpoints. +- **Middleware Mode**: Embed into Express, NestJS, or any connect-compatible server. +- **Cluster Mode**: Scale across all CPU cores in production. + +## Docs + +- [Guide](https://react-server.dev/guide): Overview of guides covering getting started, server components, client components, server functions +- [Get Started](https://react-server.dev/guide/get-started): How to set up prerequisites (Node.js/Bun/Deno) and create your first application from a single file to a full-featured app +- [Quick Start](https://react-server.dev/guide/quick-start): Minimal steps to run a React Server Component with a single file and one command using npx +- [Server Components](https://react-server.dev/guide/server-components): How React Server Components work — rendered on the server, streamed as HTML/JSON, supporting async data fetching and Suspense +- [Client Components](https://react-server.dev/guide/client-components): How to create interactive client-side components using the "use client" directive with server-side rendering and lazy-loaded hydration +- [Server Functions](https://react-server.dev/guide/server-functions): How to define and call server-side async functions from client code using "use server" including inline, module-level, and form-based usage +- [Architecture Tradeoffs](https://react-server.dev/guide/design-decisions): Key architectural decisions, layered runtime structure, constraints, and tradeoffs of the runtime design +- [Features](https://react-server.dev/features): Overview of runtime features including CLI, configuration, HTTP context, caching, error handling, PPR, cluster mode, middleware mode, micro-frontends, and workers +- [CLI](https://react-server.dev/features/cli): Reference for the @lazarv/react-server CLI commands: dev server, build, start, and available flags/options +- [Configuration](https://react-server.dev/features/configuration): How to configure @lazarv/react-server using react-server.config files (JS/TS/JSON), Vite config extension, environment-specific and runtime configs +- [Caching](https://react-server.dev/features/caching): Response caching, in-memory cache with TTL, compound cache keys, cache providers, cache profiles, and cache invalidation/revalidation +- [HTTP Context](https://react-server.dev/features/http): How to access and manipulate the full HTTP context (request, response, headers, cookies, redirects, rewrites) during SSR and middleware +- [Error Handling](https://react-server.dev/features/error-handling): Using the built-in ErrorBoundary component to catch and handle errors in server components with fallback and error display components +- [Middleware Mode](https://react-server.dev/features/middleware-mode): Running @lazarv/react-server as middleware inside existing servers like Express or NestJS in both dev and production +- [Cluster Mode](https://react-server.dev/features/cluster): Running the production server in multi-process cluster mode to utilize all CPU cores +- [Partial Pre-Rendering](https://react-server.dev/features/ppr): Pre-rendering static shells at build time while deferring dynamic content to runtime using "use dynamic" and "use static" directives +- [Live Components](https://react-server.dev/features/live-components): Real-time streaming components using the "use live" directive with async generator functions pushing updates over WebSocket +- [Workers](https://react-server.dev/features/worker): Offloading heavy computations to separate threads using "use worker" with RSC-based serialization — Node.js Worker Threads on server, Web Workers on client +- [Micro-Frontends](https://react-server.dev/features/micro-frontends): Implementing micro-frontend architecture with RemoteComponent for loading and rendering remote React applications with SSR +- [MCP Server](https://react-server.dev/features/mcp): Exposing typed server functions as discoverable tools, resources, and prompts for language models and automation agents via the Model Context Protocol +- [Server Function Encryption](https://react-server.dev/features/server-function-encryption): AES-256-GCM encryption of server function identifiers to prevent unauthorized discovery and invocation +- [Router](https://react-server.dev/router): Overview of the file-system based router and low-level routing covering route definition, client navigation, outlets, middlewares, and API routes +- [File-System Router](https://react-server.dev/router/file-router): How to use the file-system based router that activates automatically when no entrypoint is specified +- [Define Routes](https://react-server.dev/router/define-routes): How to define routes using file-system conventions including layouts, nested routes, dynamic routes, catch-all routes, and route groups +- [Client-Side Navigation](https://react-server.dev/router/client-navigation): Client-side navigation components (Link, Refresh, Redirect) and hooks for programmatic navigation, prefetching, and page refresh +- [Outlets](https://react-server.dev/router/outlets): Creating nested layouts with named outlets using @-prefixed subdirectories that pass matched route components as props to layouts +- [Middlewares](https://react-server.dev/router/middlewares): File-system based server middlewares using .middleware.{js,mjs,ts,mts} files for authentication, logging, redirects, and request processing +- [Server-Side Routing](https://react-server.dev/router/server-routing): Low-level server-side routing using the Route component from @lazarv/react-server/router for programmatic route definition +- [API Routes](https://react-server.dev/router/api): Defining file-system based API route handlers using .server.{js,mjs,ts,mts} files with HTTP method-based exports +- [Error Handling (Router)](https://react-server.dev/router/error-handling): Defining custom error components per layout using .error.jsx files in the file-system router for route-level error boundaries +- [Loading States](https://react-server.dev/router/loading): Defining loading state components using .loading.jsx files that show a loading indicator while pages are being fetched +- [Static Generation](https://react-server.dev/router/static): Marking pages for static generation using .static.{js,mjs,ts,mts,json} files with parameter exports for build-time pre-rendering +- [Markdown & MDX](https://react-server.dev/router/markdown): Using Markdown and MDX files as pages with Remark/Rehype plugins and React component interop +- [Router Configuration](https://react-server.dev/router/configuration): Configuring the router root path, public path, file includes/excludes, and private directories using glob patterns +- [Deploy](https://react-server.dev/deploy): Overview of deployment options with built-in adapters for Vercel, Netlify, Cloudflare, AWS, Azure, Bun, Deno, Docker, and Firebase +- [Adapters](https://react-server.dev/deploy/adapters): Overview of deployment adapters and how to configure them for different platforms +- [Vercel](https://react-server.dev/deploy/vercel): How to deploy to Vercel using the built-in adapter with project linking and configuration +- [Netlify](https://react-server.dev/deploy/netlify): How to deploy to Netlify using the built-in adapter for serverless functions and edge network +- [Cloudflare](https://react-server.dev/deploy/cloudflare): How to deploy to Cloudflare Workers or Pages using the built-in adapter for edge runtime +- [Bun](https://react-server.dev/deploy/bun): How to deploy as a standalone Bun server using Bun.serve() with auto-detected adapter +- [Deno](https://react-server.dev/deploy/deno): How to deploy as a standalone Deno server using Deno.serve() with auto-detected adapter +- [Docker](https://react-server.dev/deploy/docker): How to deploy with Docker using a production-ready Alpine-based Node.js image +- [AWS Lambda](https://react-server.dev/deploy/aws): How to deploy to AWS Lambda with CloudFront CDN using AWS SAM and the built-in adapter +- [Azure Functions](https://react-server.dev/deploy/azure): How to deploy to Azure Functions v4 with full response streaming support +- [Azure Static Web Apps](https://react-server.dev/deploy/azure-swa): How to deploy to Azure Static Web Apps using SWA managed functions and CDN-backed static hosting +- [Firebase Functions](https://react-server.dev/deploy/firebase): How to deploy to Firebase Cloud Functions v2 with Firebase Hosting rewrites and response streaming +- [Adapter API](https://react-server.dev/deploy/api): How to create custom deployment adapters using the createAdapter API from @lazarv/react-server/adapters/core +- [Integrations](https://react-server.dev/integrations): Overview of integrations with Vite, TypeScript, Tailwind CSS, TanStack Query, Mantine UI, and Material UI +- [Vite](https://react-server.dev/integrations/vite): How @lazarv/react-server is built on the Vite Environment API with Vite config, env variables, plugins, CSS, and migration support +- [TypeScript](https://react-server.dev/integrations/typescript): How to configure and use TypeScript with @lazarv/react-server via standard tsconfig.json +- [Tailwind CSS](https://react-server.dev/integrations/tailwind-css): How to install and configure Tailwind CSS v3 or v4 with @lazarv/react-server using PostCSS or the Vite plugin +- [TanStack Query](https://react-server.dev/integrations/react-query): How to integrate TanStack Query for server-side prefetching and client-side hydration of data +- [Mantine UI](https://react-server.dev/integrations/mantine): How to integrate Mantine component library with PostCSS configuration and MantineProvider theming +- [Material UI](https://react-server.dev/integrations/mui): How to integrate Material UI (MUI) with Emotion CSS-in-JS styling for server-side rendered components +- [Tutorials](https://react-server.dev/tutorials): Step-by-step tutorials for Hello World, Todo App, and Photos gallery +- [Hello World Tutorial](https://react-server.dev/tutorials/hello-world): Step-by-step tutorial to create a Hello World application with React Server Components +- [Todo App Tutorial](https://react-server.dev/tutorials/todo-app): Tutorial to build a Todo app using only React Server Components and Server Functions with SQLite +- [Photos Tutorial](https://react-server.dev/tutorials/photos): Tutorial to build a photo gallery using client components, file-system routing, and interactive navigation + +## CLI Reference + +Commands: +- `react-server [entrypoint]` — Start development server +- `react-server build [entrypoint]` — Production build +- `react-server start` — Start production server + +Key flags: `--open`, `--port`, `--host`, `--https`, `--export`, `--deploy`, `--edge`, `--compression`, `--adapter `, `--eval`, `--sourcemap`, `--trust-proxy`, `--build`, `--cluster ` + +## File-System Router Conventions + +When no entrypoint is specified, the file-system router activates: + +``` +app/ +├── layout.jsx # Root layout +├── page.jsx # / (index page) +├── about.jsx # /about +├── posts/ +│ ├── page.jsx # /posts +│ ├── [id].jsx # /posts/:id (dynamic route) +│ └── [...slug].jsx # /posts/* (catch-all route) +├── (auth)/ +│ └── login.jsx # /login (route group, no URL segment) +├── @sidebar/ +│ └── page.jsx # Parallel outlet +├── loading.jsx # Suspense loading fallback +├── error.jsx # Error boundary +├── (i18n).middleware.mjs # Middleware +└── GET.api.server.mjs # GET /api (REST API endpoint) +``` + +Configure routing root directory in `react-server.config.json`: + +```json +{ + "root": "app" +} +``` + +## Configuration + +Auto-detected from `react-server.config.{js,mjs,ts,mts,json}`. Supports: +- Environment-specific variants: `.production.config.*`, `.development.config.*` +- Extension configs: `+*.config.*` +- Runtime-only configs: `.runtime.config.*` +- Vite config: `vite.config.*` is merged automatically + +```js +export default { + root: "app", + public: "public", + cluster: 4, + prerender: { timeout: 5000 }, + cache: { + profiles: { default: { ttl: 60000 } }, + }, +}; +``` + +## Imports + +Key package exports for application code: + +- `@lazarv/react-server/navigation` — Link, Form, Refresh, Redirect components for client-side navigation +- `@lazarv/react-server/client` — useClient() hook for programmatic navigation (navigate, prefetch, refresh) +- `@lazarv/react-server/router` — Route component for server-side routing +- `@lazarv/react-server/http` — HTTP context hooks: useUrl, usePathname, useSearchParams, useRequest, useResponse, headers, cookie, redirect, rewrite, status, useResponseCache +- `@lazarv/react-server/cache` — useCache, revalidate, invalidate for data caching +- `@lazarv/react-server/error` — ErrorBoundary component +- `@lazarv/react-server/remote` — RemoteComponent for micro-frontends +- `@lazarv/react-server/mcp` — createServer, createTool, createResource, createPrompt for MCP server +- `@lazarv/react-server/dev` — reactServer() for middleware mode in development +- `@lazarv/react-server/node` — reactServer() for middleware mode in production +- `@lazarv/react-server/adapters/core` — createAdapter for custom deployment adapters + +## Deployment + +Build and deploy with one command: + +```sh +react-server build --deploy +``` + +Specify the adapter in config: + +```json +{ + "adapter": "vercel" +} +``` + +Supported platforms: Vercel, Netlify, Cloudflare, AWS Lambda, Azure Functions, Azure Static Web Apps, Firebase Functions, Bun, Deno, Docker. + +## Runtime Support + +- Node.js >= 20.10 +- Bun >= 1.2.9 +- Deno >= 2.0 + +## Optional: Source and Examples + +- GitHub: https://github.com/lazarv/react-server +- npm: https://www.npmjs.com/package/@lazarv/react-server +- Scaffolding: `npx @lazarv/create-react-server` diff --git a/docs/src/pages.mjs b/docs/src/pages.mjs index a8d90437..73bedb9a 100644 --- a/docs/src/pages.mjs +++ b/docs/src/pages.mjs @@ -11,7 +11,7 @@ export const pages = Array.from( export const categories = [ "Guide", "Integrations", - "Framework", + "Features", "Router", "Deploy", "Tutorials", diff --git a/docs/src/pages/(root).layout.jsx b/docs/src/pages/(root).layout.jsx index 97251703..5ead0ea9 100644 --- a/docs/src/pages/(root).layout.jsx +++ b/docs/src/pages/(root).layout.jsx @@ -73,15 +73,9 @@ export default function Layout({ - + - + - {m.category_framework()} + {m.category_features()} ## Additional configuration -The following options are specific to the `@lazarv/react-server` framework. +The following options are specific to `@lazarv/react-server`. #### Runtime @@ -154,7 +154,7 @@ export default { }; ``` -As the whole application context is available in the function, you can use all helpers or hooks provided by the framework to determine whether to preload the client components. +As the whole application context is available in the function, you can use all helpers or hooks provided by `@lazarv/react-server` to determine whether to preload the client components. ```mjs filename="react-server.config.mjs" import { usePathname } from "@lazarv/react-server"; diff --git a/docs/src/pages/en/(pages)/framework/error-handling.mdx b/docs/src/pages/en/(pages)/features/error-handling.mdx similarity index 99% rename from docs/src/pages/en/(pages)/framework/error-handling.mdx rename to docs/src/pages/en/(pages)/features/error-handling.mdx index 23c0cb20..72311d60 100644 --- a/docs/src/pages/en/(pages)/framework/error-handling.mdx +++ b/docs/src/pages/en/(pages)/features/error-handling.mdx @@ -1,6 +1,6 @@ --- title: Error handling -category: Framework +category: Features order: 2 --- diff --git a/docs/src/pages/en/(pages)/framework/http.mdx b/docs/src/pages/en/(pages)/features/http.mdx similarity index 93% rename from docs/src/pages/en/(pages)/framework/http.mdx rename to docs/src/pages/en/(pages)/features/http.mdx index 0350e640..7d47df69 100644 --- a/docs/src/pages/en/(pages)/framework/http.mdx +++ b/docs/src/pages/en/(pages)/features/http.mdx @@ -1,6 +1,6 @@ --- title: HTTP context -category: Framework +category: Features order: 0 --- @@ -12,7 +12,7 @@ With `@lazarv/react-server` you have access to everything related to the context The following hooks / functions are available for you to access and manipulate the HTTP context. -All of these functions are available also in middlewares and route handlers with the file-system based router as these are framework specific and not related to React. +All of these functions are available also in middlewares and route handlers with the file-system based router as these are runtime specific and not related to React. With `useHttpContext()` you can get access to the full HTTP context. @@ -270,7 +270,7 @@ export default function MyComponent() { With `redirect()` you can redirect the current request to another URL. -> **Warning:** the `redirect()` function will throw an error which will be caught by the framework and will result in a redirect. When you want to use `redirect()` in a `try`/`catch` block, make sure you rethrow the error if it's a redirect error. +> **Warning:** the `redirect()` function will throw an error which will be caught by the runtime and will result in a redirect. When you want to use `redirect()` in a `try`/`catch` block, make sure you rethrow the error if it's a redirect error. ```jsx import { redirect } from "@lazarv/react-server"; @@ -415,7 +415,7 @@ export default function MyComponent() { ## Logger -With `logger` you can log messages using the framework's built-in logger. The `logger` object provides `info`, `warn`, `error`, and `debug` methods that integrate with the framework's logging system, providing consistent and formatted output. +With `logger` you can log messages using the runtime's built-in logger. The `logger` object provides `info`, `warn`, `error`, and `debug` methods that integrate with the runtime's logging system, providing consistent and formatted output. ```jsx import { logger } from "@lazarv/react-server"; @@ -427,7 +427,7 @@ export default function MyComponent() { } ``` -The `logger` automatically uses the framework's Vite-integrated logger in development mode for nicely formatted output, and falls back to `console` in production. It is context-aware — when called inside an `after()` callback, the log output is annotated with an `(after)` label so you can distinguish post-response logs from rendering logs. +The `logger` automatically uses the runtime's Vite-integrated logger in development mode for nicely formatted output, and falls back to `console` in production. It is context-aware — when called inside an `after()` callback, the log output is annotated with an `(after)` label so you can distinguish post-response logs from rendering logs. ```jsx import { after, logger } from "@lazarv/react-server"; diff --git a/docs/src/pages/en/(pages)/framework/live-components.mdx b/docs/src/pages/en/(pages)/features/live-components.mdx similarity index 65% rename from docs/src/pages/en/(pages)/framework/live-components.mdx rename to docs/src/pages/en/(pages)/features/live-components.mdx index 729a7115..6d0f2b65 100644 --- a/docs/src/pages/en/(pages)/framework/live-components.mdx +++ b/docs/src/pages/en/(pages)/features/live-components.mdx @@ -1,6 +1,6 @@ --- title: Live Components -category: Framework +category: Features order: 13 --- @@ -8,9 +8,9 @@ import Link from "../../../../components/Link.jsx"; # Live Components -Live Components are a powerful feature of the `@lazarv/react-server` framework that allows you to create interactive components that can update in real-time without requiring a full page reload. This is particularly useful for applications that require dynamic content updates, such as chat applications, dashboards, or collaborative tools. +Live Components are a powerful feature of `@lazarv/react-server` that allows you to create interactive components that can update in real-time without requiring a full page reload. This is particularly useful for applications that require dynamic content updates, such as chat applications, dashboards, or collaborative tools. -> **Note:** Live Components are designed to work seamlessly with the `@lazarv/react-server` framework, and they leverage the power of React Server Components to provide a smooth and efficient user experience. However, they are still an experimental feature, and you should use them with caution in production applications. +> **Note:** Live Components are designed to work seamlessly with `@lazarv/react-server`, and they leverage the power of React Server Components to provide a smooth and efficient user experience. However, they are still an experimental feature, and you should use them with caution in production applications. ## Why Live Components? @@ -39,7 +39,7 @@ export default async function* LiveComponent() { } ``` -The framework will create a special outlet for this component, allowing it to update in real-time. The component will re-render every second, displaying the current time without requiring a full page reload or any user interaction. +The runtime will create a special outlet for this component, allowing it to update in real-time. The component will re-render every second, displaying the current time without requiring a full page reload or any user interaction. You can use Live Components in your application by importing them and rendering them like any other React component: @@ -58,7 +58,7 @@ export default function Home() { This will render the Live Component on the page, and it will update every second to show the current time. -You can also use Live Components in combination with other features of the `@lazarv/react-server` framework, such as server functions and client components, to create rich, interactive applications that respond to user input and data changes in real-time. +You can also use Live Components in combination with other features of `@lazarv/react-server`, such as server functions and client components, to create rich, interactive applications that respond to user input and data changes in real-time. Each Live Component instance is runs in it's own context, so you can have multiple instances of the same Live Component on the same page, each with its own state and updates. This allows you to create complex, interactive UIs that can handle multiple live updates simultaneously. @@ -70,6 +70,6 @@ Each Live Component instance is runs in it's own context, so you can have multip Live Components are using [socket.io](https://socket.io/) under the hood to establish a WebSocket connection between the server and the client. This allows the server to push updates to the client in real-time, enabling the Live Components to update without requiring a full page reload. -When you use the `"use live"` directive, the framework automatically sets up the necessary WebSocket connection and manages the communication between the server and the client. This means you can focus on building your Live Components without worrying about the underlying implementation details. +When you use the `"use live"` directive, the runtime automatically sets up the necessary WebSocket connection and manages the communication between the server and the client. This means you can focus on building your Live Components without worrying about the underlying implementation details. -> **Note:** Live Components are built on top of WebSockets, but in the future, the framework may support other protocols for real-time communication, such as Server-Sent Events (SSE) or HTTP/2 push. This will allow you to choose the best protocol for your application's needs and ensure optimal performance and compatibility across different browsers and devices. +> **Note:** Live Components are built on top of WebSockets, but in the future, the runtime may support other protocols for real-time communication, such as Server-Sent Events (SSE) or HTTP/2 push. This will allow you to choose the best protocol for your application's needs and ensure optimal performance and compatibility across different browsers and devices. diff --git a/docs/src/pages/en/(pages)/framework/mcp.mdx b/docs/src/pages/en/(pages)/features/mcp.mdx similarity index 95% rename from docs/src/pages/en/(pages)/framework/mcp.mdx rename to docs/src/pages/en/(pages)/features/mcp.mdx index 4efac655..a172aa9c 100644 --- a/docs/src/pages/en/(pages)/framework/mcp.mdx +++ b/docs/src/pages/en/(pages)/features/mcp.mdx @@ -1,6 +1,6 @@ --- title: MCP -category: Framework +category: Features order: 15 --- @@ -183,15 +183,15 @@ export default async function MyClientComponent() { This will allow you to fetch the resource data when the button is clicked, demonstrating how MCP handlers can be used in both server and client components to provide a seamless experience. -Don't forget to annotate your MCP handlers with the `"use server"` directive to ensure they are treated as server-side functions. This is important for the `@lazarv/react-server` framework to correctly expose the handlers and allow them to be invoked by your application. +Don't forget to annotate your MCP handlers with the `"use server"` directive to ensure they are treated as server-side functions. This is important for `@lazarv/react-server` to correctly expose the handlers and allow them to be invoked by your application. -MCP handlers are called using Server Functions in your application, while exposed to MCP clients using the `createServer` function. This allows you to define your handlers in a way that is compatible with both the `@lazarv/react-server` framework and the Model Context Protocol, enabling seamless integration and interaction with language models and other automated agents. +MCP handlers are called using Server Functions in your application, while exposed to MCP clients using the `createServer` function. This allows you to define your handlers in a way that is compatible with both `@lazarv/react-server` and the Model Context Protocol, enabling seamless integration and interaction with language models and other automated agents. ## Authentication -`@lazarv/react-server` does not currently support MCP authentication, so you will need to implement your own authentication mechanism if you want to secure your MCP handlers. You can use the framework's built-in hooks, such as `cookie` or `headers`, to manage authentication and authorization for your MCP endpoints. +`@lazarv/react-server` does not currently support MCP authentication, so you will need to implement your own authentication mechanism if you want to secure your MCP handlers. You can use the runtime's built-in hooks, such as `cookie` or `headers`, to manage authentication and authorization for your MCP endpoints. ## Sessions diff --git a/docs/src/pages/en/(pages)/framework/micro-frontends.mdx b/docs/src/pages/en/(pages)/features/micro-frontends.mdx similarity index 98% rename from docs/src/pages/en/(pages)/framework/micro-frontends.mdx rename to docs/src/pages/en/(pages)/features/micro-frontends.mdx index 535e49b9..adf91354 100644 --- a/docs/src/pages/en/(pages)/framework/micro-frontends.mdx +++ b/docs/src/pages/en/(pages)/features/micro-frontends.mdx @@ -1,6 +1,6 @@ --- title: Micro-frontends -category: Framework +category: Features order: 12 --- @@ -41,7 +41,7 @@ export default function MicroFrontend() { Just don't use `html`, `head` or `body` tags in your micro-frontend route as the hosting application can't render multiple of these tags. -> **Note:** React Server Components, client components and server functions are all supported in micro-frontends when using the `@lazarv/react-server` framework using server-side rendering. +> **Note:** React Server Components, client components and server functions are all supported in micro-frontends when using `@lazarv/react-server` with server-side rendering. `@lazarv/react-server` provides a set of tools to help you implement micro-frontends in your application. You can use the `RemoteComponent` component to load a micro-frontend from a remote URL. This allows you to load a micro-frontend on demand and render it in your application using server-side rendering. diff --git a/docs/src/pages/en/(pages)/framework/middleware-mode.mdx b/docs/src/pages/en/(pages)/features/middleware-mode.mdx similarity index 99% rename from docs/src/pages/en/(pages)/framework/middleware-mode.mdx rename to docs/src/pages/en/(pages)/features/middleware-mode.mdx index 31503c8f..21d53c38 100644 --- a/docs/src/pages/en/(pages)/framework/middleware-mode.mdx +++ b/docs/src/pages/en/(pages)/features/middleware-mode.mdx @@ -1,6 +1,6 @@ --- title: Middleware mode -category: Framework +category: Features order: 11 --- diff --git a/docs/src/pages/en/(pages)/framework/ppr.mdx b/docs/src/pages/en/(pages)/features/ppr.mdx similarity index 88% rename from docs/src/pages/en/(pages)/framework/ppr.mdx rename to docs/src/pages/en/(pages)/features/ppr.mdx index 014a0306..3e3d586d 100644 --- a/docs/src/pages/en/(pages)/framework/ppr.mdx +++ b/docs/src/pages/en/(pages)/features/ppr.mdx @@ -1,6 +1,6 @@ --- title: Partial pre-rendering -category: Framework +category: Features order: 5 --- @@ -8,7 +8,7 @@ import Link from "../../../../components/Link.jsx"; # Partial pre-rendering -When you have a page that contains a static shell and dynamic content, you can use partial pre-rendering to pre-render only the static content and then the framework will use the pre-rendered content and a state stored in a JSON file to continue rendering the dynamic content on demand. +When you have a page that contains a static shell and dynamic content, you can use partial pre-rendering to pre-render only the static content and then the runtime will use the pre-rendered content and a state stored in a JSON file to continue rendering the dynamic content on demand. You can split your JSX to static and dynamic content by using Suspense and marking dynamic components by using the `'use dynamic'` directive. The marked component's rendering will be "postponed" for rendering it at runtime in the production server using the pre-rendered HTML content, the JSON state used to resume rendering and the cache entries of all components using the `'use static'` directive. @@ -58,7 +58,7 @@ export default { ## Disable partial pre-rendering -When you run the `build` command, the framework will pre-render the pages you have exported and store the pre-rendered content in the `.react-server` folder of your project. The pre-rendered content will be used by the production server to render the pages faster. +When you run the `build` command, the runtime will pre-render the pages you have exported and store the pre-rendered content in the `.react-server` folder of your project. The pre-rendered content will be used by the production server to render the pages faster. To disable partial pre-rendering, add `prerender: false` to your `react-server.config.mjs`: diff --git a/docs/src/pages/en/(pages)/framework/server-function-encryption.mdx b/docs/src/pages/en/(pages)/features/server-function-encryption.mdx similarity index 93% rename from docs/src/pages/en/(pages)/framework/server-function-encryption.mdx rename to docs/src/pages/en/(pages)/features/server-function-encryption.mdx index ab6cb6e1..c2a01d03 100644 --- a/docs/src/pages/en/(pages)/framework/server-function-encryption.mdx +++ b/docs/src/pages/en/(pages)/features/server-function-encryption.mdx @@ -1,6 +1,6 @@ --- title: Server function encryption -category: Framework +category: Features order: 3 --- @@ -39,14 +39,14 @@ This means server function encryption is always active. You only need to configu ## Custom secret -You can provide your own encryption secret using environment variables or the framework configuration. This is useful when you need deterministic keys across deployments or when running multiple server instances. +You can provide your own encryption secret using environment variables or the runtime configuration. This is useful when you need deterministic keys across deployments or when running multiple server instances. The secret is resolved in the following priority order: 1. `REACT_SERVER_FUNCTIONS_SECRET` environment variable 2. `REACT_SERVER_FUNCTIONS_SECRET_FILE` environment variable (path to a key file) -3. `serverFunctions.secret` in the framework configuration -4. `serverFunctions.secretFile` in the framework configuration (path to a key file) +3. `serverFunctions.secret` in the runtime configuration +4. `serverFunctions.secretFile` in the runtime configuration (path to a key file) 5. Build artifact (generated automatically during production builds) 6. Ephemeral random key (development fallback) @@ -64,8 +64,8 @@ Or point to a key file: REACT_SERVER_FUNCTIONS_SECRET_FILE=./keys/action-secret.pem pnpm start ``` - -### Framework configuration + +### Runtime configuration ```mjs filename="react-server.config.mjs" diff --git a/docs/src/pages/en/(pages)/framework/worker.mdx b/docs/src/pages/en/(pages)/features/worker.mdx similarity index 89% rename from docs/src/pages/en/(pages)/framework/worker.mdx rename to docs/src/pages/en/(pages)/features/worker.mdx index e313d58a..fb9427fc 100644 --- a/docs/src/pages/en/(pages)/framework/worker.mdx +++ b/docs/src/pages/en/(pages)/features/worker.mdx @@ -1,6 +1,6 @@ --- title: Workers -category: Framework +category: Features order: 14 --- @@ -8,7 +8,7 @@ import Link from "../../../../components/Link.jsx"; # Workers -The `"use worker"` directive in the `@lazarv/react-server` framework lets you offload heavy computations or blocking tasks to separate threads. On the server, functions marked with `"use worker"` run in a **Node.js Worker Thread** (`node:worker_threads`). On the client, the same directive runs your code in a **Web Worker** (browser `Worker` API). In both cases, you import and call worker functions as if they were ordinary async functions — the framework handles thread creation, message passing, and serialization transparently. +The `"use worker"` directive in `@lazarv/react-server` lets you offload heavy computations or blocking tasks to separate threads. On the server, functions marked with `"use worker"` run in a **Node.js Worker Thread** (`node:worker_threads`). On the client, the same directive runs your code in a **Web Worker** (browser `Worker` API). In both cases, you import and call worker functions as if they were ordinary async functions — the runtime handles thread creation, message passing, and serialization transparently. All data flowing between the main thread and the worker is serialized using the **React Server Components (RSC) Flight protocol**. This means worker functions can return not only plain values but also **React elements**, **Suspense boundaries**, **Promises** (for deferred rendering with the `use()` hook), and **ReadableStreams**. @@ -18,14 +18,14 @@ All data flowing between the main thread and the worker is serialized using the - **Non-blocking rendering:** CPU-intensive work (prime sieves, sorting, matrix math, image processing) runs off the main thread so it doesn't block server request handling or the browser UI. - **Concurrency:** Multiple worker calls can execute in parallel, improving throughput. -- **Unified API:** The same `"use worker"` directive works in both server and client code. You write one module and the framework picks the right threading primitive for the environment. +- **Unified API:** The same `"use worker"` directive works in both server and client code. You write one module and the runtime picks the right threading primitive for the environment. - **RSC-native serialization:** Because data is serialized via the Flight protocol, you can seamlessly pass and return React elements, Suspense boundaries, ReadableStreams, and deferred Promises between threads. ## How It Works -When the framework encounters a file with `"use worker"` at the top, it replaces all exports with thin proxy functions at build time. The original module code is moved into a virtual module that runs inside the worker thread. When you call an exported function, the proxy: +When the runtime encounters a file with `"use worker"` at the top, it replaces all exports with thin proxy functions at build time. The original module code is moved into a virtual module that runs inside the worker thread. When you call an exported function, the proxy: 1. Serializes the arguments using the RSC Flight protocol. 2. Posts a message to the worker thread (or Web Worker) with the function name and serialized arguments. @@ -149,7 +149,7 @@ export async function getWorkerSystemInfo() { ## Returning React Elements -Because communication uses the RSC Flight protocol, worker functions can return **React elements**, including components with **Suspense boundaries**. The framework serializes the entire component tree and reconstructs it on the calling side. +Because communication uses the RSC Flight protocol, worker functions can return **React elements**, including components with **Suspense boundaries**. The runtime serializes the entire component tree and reconstructs it on the calling side. ```jsx "use worker"; @@ -303,7 +303,7 @@ When the request is aborted (e.g., the client navigates away), `signal.aborted` ## Client-Side Web Workers -The same `"use worker"` directive works in client-side code. When a `"use client"` component imports from a `"use worker"` module, the framework automatically creates a **Web Worker** in the browser. The function arguments and return values are serialized using the RSC Flight protocol and transferred between the main thread and the Web Worker. +The same `"use worker"` directive works in client-side code. When a `"use client"` component imports from a `"use worker"` module, the runtime automatically creates a **Web Worker** in the browser. The function arguments and return values are serialized using the RSC Flight protocol and transferred between the main thread and the Web Worker. This keeps the browser's main thread responsive while heavy computation runs in the background — no UI jank, no frozen interactions. @@ -469,7 +469,7 @@ export async function streamComputations() { ## Edge Runtime Behavior -On **edge and serverless runtimes** (Cloudflare Workers, Vercel Edge, Netlify Edge, Deno Deploy), `node:worker_threads` is not available. In these environments, the framework automatically falls back to **in-process execution** — your worker functions are called directly without any threading or serialization overhead. +On **edge and serverless runtimes** (Cloudflare Workers, Vercel Edge, Netlify Edge, Deno Deploy), `node:worker_threads` is not available. In these environments, the runtime automatically falls back to **in-process execution** — your worker functions are called directly without any threading or serialization overhead. This means `"use worker"` modules remain fully portable: the same code works in Node.js (with real worker threads) and on the edge (with direct execution). You don't need to change your code or add conditional logic. @@ -479,7 +479,7 @@ This means `"use worker"` modules remain fully portable: the same code works in ## Worker Detection -The framework provides an `isWorker()` helper function that lets you detect at runtime whether your code is executing inside a worker thread. This is useful when you need to conditionally run logic that should only happen inside a real worker — for example, calling `process.exit()` to terminate the worker without accidentally killing the main server process. +The runtime provides an `isWorker()` helper function that lets you detect at runtime whether your code is executing inside a worker thread. This is useful when you need to conditionally run logic that should only happen inside a real worker — for example, calling `process.exit()` to terminate the worker without accidentally killing the main server process. Import `isWorker` from `@lazarv/react-server/worker`. This import path works in both server workers (Node.js Worker Threads) and client workers (Web Workers): @@ -562,7 +562,7 @@ Keep the following constraints in mind when using `"use worker"`: ### Development mode -- In development, the framework uses Vite's `ModuleRunner` inside the worker thread, providing full **Hot Module Replacement (HMR)** support. Changes to worker files are picked up automatically without restarting the dev server. +- In development, the runtime uses Vite's `ModuleRunner` inside the worker thread, providing full **Hot Module Replacement (HMR)** support. Changes to worker files are picked up automatically without restarting the dev server. ## Full Example diff --git a/docs/src/pages/en/(pages)/guide/design-decisions.mdx b/docs/src/pages/en/(pages)/guide/design-decisions.mdx index 7619fae2..e064a9b7 100644 --- a/docs/src/pages/en/(pages)/guide/design-decisions.mdx +++ b/docs/src/pages/en/(pages)/guide/design-decisions.mdx @@ -46,15 +46,15 @@ React Server Components depend on an unstable wire format between `react-server- The RSC wire format must be version-locked across the server renderer, the client hydrator, and the flight encoder/decoder. Allowing user-installed React creates a combinatorial compatibility surface that cannot be tested reliably since React publishes experimental builds frequently with breaking internal changes. **Decision:** -Bundle a specific React experimental build as a direct dependency. At startup, hijack module resolution so all imports of `react`, `react-dom`, `react/jsx-runtime`, and `react-server-dom-webpack` resolve to the framework's bundled copies. On Node.js this uses `module.register()` with a custom loader; on Bun it uses `module.mock()`/`module.alias()`; on Deno it writes an import map to disk and respawns the process with `--import-map`. +Bundle a specific React experimental build as a direct dependency. At startup, hijack module resolution so all imports of `react`, `react-dom`, `react/jsx-runtime`, and `react-server-dom-webpack` resolve to the runtime's bundled copies. On Node.js this uses `module.register()` with a custom loader; on Bun it uses `module.mock()`/`module.alias()`; on Deno it writes an import map to disk and respawns the process with `--import-map`. **Tradeoffs:** -- Users cannot upgrade React independently. Adoption of new React features is gated by a framework release. +- Users cannot upgrade React independently. Adoption of new React features is gated by a runtime release. - The module aliasing mechanism is runtime-specific and fragile — each JavaScript runtime (Node, Bun, Deno) requires a distinct interception strategy. A bug in any one path silently breaks the entire RSC pipeline. - The Deno path requires a filesystem write and process respawn, adding startup latency and preventing use in read-only filesystem environments. **Consequences:** -The wire format is guaranteed consistent across all render paths. Users do not need to install React — reducing dependency conflicts and version drift. But the framework's release cadence becomes the bottleneck for React upgrades, and the three-way aliasing layer is a maintenance surface that must be verified against each runtime's release cycle. +The wire format is guaranteed consistent across all render paths. Users do not need to install React — reducing dependency conflicts and version drift. But the runtime's release cadence becomes the bottleneck for React upgrades, and the three-way aliasing layer is a maintenance surface that must be verified against each runtime's release cycle. ### Multi-Runtime Execution @@ -185,7 +185,7 @@ export default function App() { ``` **Tradeoffs:** -- [HTTP status codes and headers](/framework/http) must be determined before the stream begins. Errors or redirects that occur mid-stream cannot change the status code retroactively. +- [HTTP status codes and headers](/features/http) must be determined before the stream begins. Errors or redirects that occur mid-stream cannot change the status code retroactively. - Proxy servers, CDNs, or middleware that buffer the full response negate the streaming benefit. - Debugging streaming responses is harder than inspecting a single HTML payload. @@ -230,7 +230,7 @@ Conventional RSC renders are request-response: the server renders once and sends Updates must be React trees, not raw data — the client must receive renderable RSC payloads, not JSON that requires a client-side component to interpret. Each component instance needs its own server-side execution context with independent lifecycle management. The transport must survive page-level navigation in SPAs. **Decision:** -Introduce a [`"use live"` directive](/framework/live-components). Async generator functions marked with this directive are compiled into live components. The initial `yield` is rendered as part of the normal SSR response. +Introduce a [`"use live"` directive](/features/live-components). Async generator functions marked with this directive are compiled into live components. The initial `yield` is rendered as part of the normal SSR response. ```jsx "use live"; @@ -265,7 +265,7 @@ CPU-intensive operations (image processing, data transformation, compression) on The offloading mechanism must integrate with the RSC serialization protocol — arguments and return values (including React elements) must cross the worker boundary via the flight format. On the server this means `node:worker_threads`; in the browser this means Web Workers. Edge runtimes have neither. **Decision:** -Introduce a [`"use worker"` directive](/framework/worker). The Vite plugin rewrites the module into a proxy: on Node.js/Bun, each call spawns or reuses a `Worker` thread with arguments serialized via the RSC flight protocol and transferred via `postMessage`. +Introduce a [`"use worker"` directive](/features/worker). The Vite plugin rewrites the module into a proxy: on Node.js/Bun, each call spawns or reuses a `Worker` thread with arguments serialized via the RSC flight protocol and transferred via `postMessage`. ```jsx "use worker"; @@ -298,7 +298,7 @@ Large organizations deploy frontend applications across multiple teams and repos Remote components must produce RSC flight payloads consumable by the host application. Client-side JavaScript from remote applications must not duplicate shared dependencies (React, react-dom) in the browser. The composition must work with the streaming and hydration pipeline without special client-side glue code. **Decision:** -Provide a [``](/framework/micro-frontends) primitive that fetches RSC flight data from a remote react-server instance at render time. +Provide a [``](/features/micro-frontends) primitive that fetches RSC flight data from a remote react-server instance at render time. ```jsx import RemoteComponent from "@lazarv/react-server/remote"; @@ -316,7 +316,7 @@ export default function Home() { The host fetches the remote's browser manifest, cross-references it with its own manifest, and emits an inline `