Overview - Router

routerWorkspace

CI Pipeline Executions
- Filtered
Runs
Demo

Insights

Compare tasks
Analytics

Overview

router

Loading workspace stats

Loading workspace insights...

Statistics interval

7 days30 days

Latest CI Pipeline Executions

Filter

Fuzzy

Sort by

© 2026 - Nx Cloud

Terms of Service Privacy Policy Changelog Status Docs Contact Nx Cloud Pricing Company @NxDevTools

routerWorkspace

Average execution time

14m 9s

125 CI pipeline executions

Computation time saved

19d 11h

Cache hit rate

39%

Time to Green

2h 4m

Was 4h 26m, improved by 53%

Failed
8405
Environment issue→
a0e2ef38 fix(react-router): memoize the Link's merged ref callback The merged ref that fills a forwarded ref alongside the link's own ref was an inline closure, so every Link render produced a new callback and React detached and re-attached it: a consumer's callback ref was called with `null` and then the element again on each location-driven re-render (3 calls after one navigation instead of 1), and an object ref was cleared and refilled inside the commit. `useImperativeHandle(ref, ..., [])` on main only re-ran when the consumer's ref changed. The callback is now memoized with `useCallback` on the forwarded ref, which restores that contract: the consumer is notified on mount, when their ref changes and on unmount. A cleanup returned by a consumer callback is still passed through to React. Nothing reads `innerRef.current` after a detach without a re-attach, so the wrapper that would clear it on cleanup is left out (+19 gzip for no observable behavior). `areLinkPropsEqual` keeps the same rule but states it in two steps, since the nested condition read as if `children` were deep-compared: element props (`children`, handlers, `style`, ...) only match by reference, and only router options fall through to `deepEqual`. Tests pin all three: a stable callback ref stays at one call across a location change and is released when swapped, a returned cleanup runs on unmount instead of a `null` call, and a new JSX child or a cyclic element prop re-renders the Link instead of being compared deeply. The ref test fails on the previous commit with `expected 1 call, got 3`. Measurements (local: macOS arm64, Node 24.8.0, production React 19.2.3): - `react-router.minimal` gzip 86008 -> 86004 (-4). The comparator restructure alone is -2; `useCallback` without the cleanup wrapper is neutral, the wrapper would have been +19. - Mount of the 200-Link benchmark app, medians of 60 runs: 4.97 ms with `useImperativeHandle` (main's mechanism on top of this branch), 4.71 ms with the inline callback, 4.69 ms memoized. Retained heap per mounted app: -23 KB against `useImperativeHandle` (its layout effect keeps an effect node, a bound function and two deps arrays per fiber pair). - Paired client runner, 3 repeats, memoized vs `useImperativeHandle`: 12/13 workloads inconclusive, `rewrites` -4.6% [-9.0, -0.2]. Memoized vs the inline callback: +2.5% [1.4, 3.7] on `param-updaters` and +1.4% [0.4, 2.5] on `relative`, where every Link re-renders per navigation and pays the extra hook; the other 11 workloads are inconclusive. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
by Manuel Sch...
M
Failed
8405
c63f63d8 fix(react-router): memoize the Link's merged ref callback The merged ref that fills a forwarded ref alongside the link's own ref was an inline closure, so every Link render produced a new callback and React detached and re-attached it: a consumer's callback ref was called with `null` and then the element again on each location-driven re-render (3 calls after one navigation instead of 1), and an object ref was cleared and refilled inside the commit. `useImperativeHandle(ref, ..., [])` on main only re-ran when the consumer's ref changed. The callback is now memoized with `useCallback` on the forwarded ref, which restores that contract: the consumer is notified on mount, when their ref changes and on unmount. A cleanup returned by a consumer callback is still passed through to React. Nothing reads `innerRef.current` after a detach without a re-attach, so the wrapper that would clear it on cleanup is left out (+19 gzip for no observable behavior). `areLinkPropsEqual` keeps the same rule but states it in two steps, since the nested condition read as if `children` were deep-compared: element props (`children`, handlers, `style`, ...) only match by reference, and only router options fall through to `deepEqual`. Tests pin all three: a stable callback ref stays at one call across a location change and is released when swapped, a returned cleanup runs on unmount instead of a `null` call, and a new JSX child or a cyclic element prop re-renders the Link instead of being compared deeply. The ref test fails on the previous commit with `expected 1 call, got 3`. Measurements (local: macOS arm64, Node 24.8.0, production React 19.2.3): - `react-router.minimal` gzip 86008 -> 86004 (-4). The comparator restructure alone is -2; `useCallback` without the cleanup wrapper is neutral, the wrapper would have been +19. - Mount of the 200-Link benchmark app, medians of 60 runs: 4.97 ms with `useImperativeHandle` (main's mechanism on top of this branch), 4.71 ms with the inline callback, 4.69 ms memoized. Retained heap per mounted app: -23 KB against `useImperativeHandle` (its layout effect keeps an effect node, a bound function and two deps arrays per fiber pair). - Paired client runner, 3 repeats, memoized vs `useImperativeHandle`: 12/13 workloads inconclusive, `rewrites` -4.6% [-9.0, -0.2]. Memoized vs the inline callback: +2.5% [1.4, 3.7] on `param-updaters` and +1.4% [0.4, 2.5] on `relative`, where every Link re-renders per navigation and pays the extra hook; the other 11 workloads are inconclusive. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
by Manuel Sch...
M
Succeeded
8405
505c9ca2 perf(react-router): memoize Link and forward refs without an effect When a layout re-renders on navigation, for instance because it reads `useLocation`, every Link below it re-renders too. Profiling 200 mounted Links showed that re-render dominated by React's per-hook update work, the element creation and the anchor's prop diff, not by the Link's own logic. A Link's output depends only on its props, the router context and the location store, all of which React tracks for memoized components, so `Link` is now wrapped in `React.memo`. Router options are compared by value, because destinations are usually inline object literals; element props are compared by reference, since they may hold arbitrary, even cyclic, user data. The comparator reuses `ROUTER_OPTION_KEYS`. The memo adds one fiber per Link. To pay for it, `useForwardedRef` goes: its `useImperativeHandle` was the only layout effect on a Link and ran for every Link although most never receive a ref. The link keeps a plain `useRef`; when a ref is forwarded, one callback fills both. The hook had no other consumer. `enqueuePreload` no longer doubles as the cleanup path: the preload effect cancels the intent timer directly. Measurements (macOS arm64, Node 24.8.0, local, against the previous commit): - Link client paired runner, 200 Links under a re-rendering layout (3 repeats): shared-params CPU -54%, masks -56%, rewrites -60%; links whose props can never compare equal (updater functions, inline `activeProps` functions) param-updaters +2.5% [-5.2, 10.9], location-updaters -1.0%, active -2.0%, all inconclusive. - retained heap per mounted app 2782 -> 2738 KB; mount unchanged within noise (the memo fiber and the removed layout effect cancel out). - react-router.minimal gzip 85968 -> 86008 (+40); the branch stays 4 bytes under the stack base. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
by Manuel Sch...
M