DOCSEARCHbyAlgolia
Submit Docs

Remix Documentation

website·Indexed 43 days ago

https://v2.remix.run

Documentation for the Remix web framework, covering routing, data loading, mutations using HTML forms, and deployment. Includes guides on the Remix Vite plugin, Single Fetch architecture, SPA mode, and migration from React Router applications.

Tokens
92K
Snippets
469
Records
587
Agent score
67%

What's inside Remix

  1. Overview of Remix Server Adapters

    Remix uses adapters to translate a server's specific request/response format into the standard Web Fetch API. This allows Remix apps to be deployed across various environments. Adapters are imported into the server's entry point and are not used within the Remix app logic itself. If using the built-in Remix App Server, these adapters are handled automatically and do not require manual interaction.

  2. Overview of Not Found (404) handling in Remix

    Remix handles 404s in two primary scenarios:

    1. URL doesn't match any routes: Remix handles this automatically. To customize this behavior, consider using a Splat Route.
    2. Loader fails to find data: This must be handled manually by throwing a Response with a 404 status from the loader.

  3. Overview of Remix SPA Mode

    SPA Mode allows you to build a Remix application that does not require a Node.js server at runtime. It generates a static index.html file at build time and relies on Client Data APIs for data loading and mutations. It is ideal for deploying to static hosts (like GitHub Pages or CDNs), migrating React Router apps to Remix, or creating embedded apps.

    Key features include:

    • File-based or config-based routing
    • Automatic route-based code-splitting via route.lazy
    • <Link prefetch> support
    • Head management via <Meta> and <Links> APIs

    SPA Mode requires the use of Vite and the Remix Vite Plugin.

  4. Overview of Single Fetch in Remix

    Single Fetch is a data loading strategy and streaming format that optimizes client-side transitions by making a single HTTP call to the server instead of multiple parallel calls (one per loader). It also enables loaders and actions to return 'naked' objects—such as Date, Error, Promise, and RegExp—without requiring manual JSON serialization.

  5. Overview of Remix Client Data loaders and actions

    Introduced in v2.4.0, Remix allows you to opt-into running route loaders and actions in the browser using clientLoader and clientAction exports. These are intended for advanced use cases rather than as the primary data mechanism. Caution is advised as manual control over client-side caching can lead to UI synchronization issues if not managed carefully.

  6. Overview of Session Management in Remix

    Sessions in Remix allow the server to identify requests from the same user. Unlike Express middleware, sessions are managed on a per-route basis within loader and action functions using a session storage object. The storage object handles parsing/generating cookies and persisting data to a backend (database, filesystem, or the cookie itself).

  7. Overview of Remix full-stack framework

    Remix is a full-stack web framework designed to deliver fast and resilient user experiences by leveraging web standards and native browser features. It is built on the Web Fetch API, allowing it to run in various environments including Cloudflare Workers, serverless functions, and traditional Node.js environments. Key architectural goals include eliminating request waterfalls through parallel server-side data loading and reducing loading states via nested routing and pre-fetching.

  8. Optimize client-side transitions with the Remix Browser Framework

    After the server delivers the initial document, Remix hydrates the page with JavaScript. The browser framework optimizes user experience by emulating browser behavior:

    • Client-side Navigation: When clicking a link, Remix fetches only the data for the next page instead of requesting a full document, updating the UI instantly.
    • Data Mutations: When a <Form> is submitted, the runtime intercepts the request and performs a fetch to the server, automatically revalidating all data on the page and updating the UI via React without a full page reload.

  9. Use MDX for build-time content in Remix

    Remix provides built-in support for MDX at build-time for users of the Classic Remix Compiler. Note that Vite users should instead use the MDX Rollup/Vite plugin. For better UX/DX and runtime customization, mdx-bundler is recommended over build-time compilation.

    There are two primary ways to use MDX:

    1. Use a .mdx or .md file as a route module in app/routes to participate in automatic file-system routing.
    2. Import a .mdx file into an existing route module.

  10. Access pending navigation metadata

    The useNavigation hook provides the following metadata about the pending transition:

    • navigation.formAction: The action URL of the submitted form, if applicable.
    • navigation.formMethod: The HTTP method of the submitted form (e.g., 'get', 'post'), if applicable.
    • navigation.location: The destination location (URL) the application is navigating to.

  11. Use the Remix App Server for production

    The Remix App Server (@remix-run/serve) is a basic, production-ready Node.js server built with Express. It is intended for users who do not need to customize the underlying server. If customization of the Express server is required, use the @remix-run/express adapter instead. The server includes the following default Express middlewares: compression, express.static (via serve-static), and morgan.
    remix-serve <server-build-path>
# Example:
remix-serve build/index.js

  12. Understand the Remix architecture and build process

    Remix is composed of four primary parts: a compiler, a server-side HTTP handler, a server framework, and a browser framework. The process begins with the compiler (remix vite:build), which uses Vite to generate three key artifacts:

    1. Server HTTP Handler: Typically located at build/server/index.js, containing all routes and modules for server-side rendering and resource handling.
    2. Browser Build: Located in build/client/*, featuring automatic route-based code splitting and fingerprinted assets.
    3. Asset Manifest: Used by both client and server to track the dependency graph, enabling the elimination of render+fetch waterfalls by preloading resources during initial render and prefetching during client transitions.