Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Update version for release #13051

Merged
merged 2 commits into from
Feb 18, 2025

Conversation

github-actions[bot]
Copy link
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to release-next, this PR will be updated.

Releases

react-router@7.2.0

Minor Changes

  • New type-safe href utility that guarantees links point to actual paths in your app (#13012)

    import { href } from "react-router";
    
    export default function Component() {
      const link = href("/blog/:slug", { slug: "my-first-post" });
      return (
        <main>
          <Link to={href("/products/:id", { id: "asdf" })} />
          <NavLink to={href("/:lang?/about", { lang: "en" })} />
        </main>
      );
    }

Patch Changes

  • Fix typegen for repeated params (#13012)

    In React Router, path parameters are keyed by their name.
    So for a path pattern like /a/:id/b/:id?/c/:id, the last :id will set the value for id in useParams and the params prop.
    For example, /a/1/b/2/c/3 will result in the value { id: 3 } at runtime.

    Previously, generated types for params incorrectly modeled repeated params with an array.
    So /a/1/b/2/c/3 generated a type like { id: [1,2,3] }.

    To be consistent with runtime behavior, the generated types now correctly model the "last one wins" semantics of path parameters.
    So /a/1/b/2/c/3 now generates a type like { id: 3 }.

  • Don't apply Single Fetch revalidation de-optimization when in SPA mode since there is no server HTTP request (#12948)

  • Properly handle revalidations to across a prerender/SPA boundary (#13021)

    • In "hybrid" applications where some routes are pre-rendered and some are served from a SPA fallback, we need to avoid making .data requests if the path wasn't pre-rendered because the request will 404
    • We don't know all the pre-rendered paths client-side, however:
      • All loader data in ssr:false mode is static because it's generated at build time
      • A route must use a clientLoader to do anything dynamic
      • Therefore, if a route only has a loader and not a clientLoader, we disable revalidation by default because there is no new data to retrieve
      • We short circuit and skip single fetch .data request logic if there are no server loaders with shouldLoad=true in our single fetch dataStrategy
      • This ensures that the route doesn't cause a .data request that would 404 after a submission
  • Error at build time in ssr:false + prerender apps for the edge case scenario of: (#13021)

    • A parent route has only a loader (does not have a clientLoader)
    • The parent route is pre-rendered
    • The parent route has children routes which are not prerendered
    • This means that when the child paths are loaded via the SPA fallback, the parent won't have any loaderData because there is no server on which to run the loader
    • This can be resolved by either adding a parent clientLoader or pre-rendering the child paths
    • If you add a clientLoader, calling the serverLoader() on non-prerendered paths will throw a 404
  • [REMOVE] Fix prerender calls to serverLoader from clientLoader (#13047)

  • Add unstable support for splitting route modules in framework mode via future.unstable_splitRouteModules (#11871)

  • Add unstable_SerializesTo brand type for library authors to register types serializable by React Router's streaming format (turbo-stream) (ab5b05b02)

  • Align dev server behavior with static file server behavior when ssr:false is set (#12948)

    • When no prerender config exists, only SSR down to the root HydrateFallback (SPA Mode)
    • When a prerender config exists but the current path is not prerendered, only SSR down to the root HydrateFallback (SPA Fallback)
    • Return a 404 on .data requests to non-pre-rendered paths
  • Improve prefetch performance of CSS side effects in framework mode (#12889)

  • Disable Lazy Route Discovery for all ssr:false apps and not just "SPA Mode" because there is no runtime server to serve the search-param-configured __manifest requests (#12894)

    • We previously only disabled this for "SPA Mode" which is ssr:false and no prerender config but we realized it should apply to all ssr:false apps, including those prerendering multiple pages
    • In those prerender scenarios we would prerender the /__manifest file assuming the static file server would serve it but that makes some unneccesary assumptions about the static file server behaviors
  • Properly handle interrupted manifest requests in lazy route discovery (#12915)

@react-router/dev@7.2.0

Minor Changes

  • Generate a "SPA fallback" HTML file for scenarios where applications are prerendering the / route with ssr:false (#12948)

    • If you specify ssr:false without a prerender config, this is considered "SPA Mode" and the generated index.html file will only render down to the root route and will be able to hydrate for any valid application path
    • If you specify ssr:false with a prerender config but do not include the / path (i.e., prerender: ['/blog/post']), then we still generate a "SPA Mode" index.html file that can hydrate for any path in the application
    • However, previously if you specified ssr:false and included the / path in your prerender config, we would prerender the / route into index.html as a non-SPA page
      • The generated HTML would include the root index route which prevented hydration for any other paths
      • With this change, we now generate a "SPA Mode" file in __spa-fallback.html that will allow you to hydrate for any non-prerendered paths
      • You can serve this file from your static file server for any paths that would otherwise 404 if you only want to pre-render some routes in your ssr:false app and serve the others as a SPA
      • npx sirv-cli build/client --single __spa-fallback.html
    • Allow a loader in the root route in SPA mode because it can be called/server-rendered at build time (#12948)
    • Route.HydrateFallbackProps now also receives loaderData
      • This will be defined so long as the HydrateFallback is rendering while children routes are loading
      • This will be undefined if the HydrateFallback is rendering because the route has it's own hydrating clientLoader
      • In SPA mode, this will allow you to render loader root data into the SPA index.html
  • New type-safe href utility that guarantees links point to actual paths in your app (#13012)

    import { href } from "react-router";
    
    export default function Component() {
      const link = href("/blog/:slug", { slug: "my-first-post" });
      return (
        <main>
          <Link to={href("/products/:id", { id: "asdf" })} />
          <NavLink to={href("/:lang?/about", { lang: "en" })} />
        </main>
      );
    }

Patch Changes

  • Handle custom envDir in Vite config (#12969)

  • Fix typegen for repeated params (#13012)

    In React Router, path parameters are keyed by their name.
    So for a path pattern like /a/:id/b/:id?/c/:id, the last :id will set the value for id in useParams and the params prop.
    For example, /a/1/b/2/c/3 will result in the value { id: 3 } at runtime.

    Previously, generated types for params incorrectly modeled repeated params with an array.
    So /a/1/b/2/c/3 generated a type like { id: [1,2,3] }.

    To be consistent with runtime behavior, the generated types now correctly model the "last one wins" semantics of path parameters.
    So /a/1/b/2/c/3 now generates a type like { id: 3 }.

  • Fix CLI parsing to allow argumentless npx react-router usage (#12925)

  • Fix ArgError: unknown or unexpected option: --version when running react-router --version (#13012)

  • Skip action-only resource routes when using prerender:true (#13004)

  • Enhance invalid export detection when using ssr:false (#12948)

    • headers/action are prohibited in all routes with ssr:false because there will be no runtime server on which to run them
    • loader functions are more nuanced and depend on whether a given route is prerendered
      • When using ssr:false without a prerender config, only the root route can have a loader
        • This is "SPA mode" which generates a single index.html file with the root route HydrateFallback so it is capable of hydrating for any path in your application - therefore we can only call a root route loader at build time
      • When using ssr:false with a prerender config, you can export a loader from routes matched by one of the prerender paths because those routes will be server rendered at build time
        • Exporting a loader from a route that is never matched by a prerender path will throw a build time error because there will be no runtime server to ever run the loader
  • Limit prerendered resource route .data files to only the target route (#13004)

  • Add unstable support for splitting route modules in framework mode via future.unstable_splitRouteModules (#11871)

  • Fix prerendering of binary files (#13039)

  • Add future.unstable_viteEnvironmentApi flag to enable experimental Vite Environment API support (#12936)

  • Disable Lazy Route Discovery for all ssr:false apps and not just "SPA Mode" because there is no runtime server to serve the search-param-configured __manifest requests (#12894)

    • We previously only disabled this for "SPA Mode" which is ssr:false and no prerender config but we realized it should apply to all ssr:false apps, including those prerendering multiple pages
    • In those prerender scenarios we would prerender the /__manifest file assuming the static file server would serve it but that makes some unneccesary assumptions about the static file server behaviors
  • [REMOVE] Update invalid route export messages (#13049)

  • Updated dependencies:

    • react-router@7.2.0
    • @react-router/node@7.2.0
    • @react-router/serve@7.2.0

@react-router/architect@7.2.0

Patch Changes

  • Updated dependencies:
    • react-router@7.2.0
    • @react-router/node@7.2.0

@react-router/cloudflare@7.2.0

Patch Changes

  • Updated dependencies:
    • react-router@7.2.0

react-router-dom@7.2.0

Patch Changes

  • Updated dependencies:
    • react-router@7.2.0

@react-router/express@7.2.0

Patch Changes

  • Updated dependencies:
    • react-router@7.2.0
    • @react-router/node@7.2.0

@react-router/fs-routes@7.2.0

Patch Changes

  • Updated dependencies:
    • @react-router/dev@7.2.0

@react-router/node@7.2.0

Patch Changes

  • Updated dependencies:
    • react-router@7.2.0

@react-router/remix-routes-option-adapter@7.2.0

Patch Changes

  • Updated dependencies:
    • @react-router/dev@7.2.0

@react-router/serve@7.2.0

Patch Changes

  • Updated dependencies:
    • react-router@7.2.0
    • @react-router/node@7.2.0
    • @react-router/express@7.2.0

create-react-router@7.2.0

@brophdawg11 brophdawg11 merged commit 4b5793d into release-next Feb 18, 2025
8 checks passed
@brophdawg11 brophdawg11 deleted the changeset-release/release-next branch February 18, 2025 20:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant