Remix loader data propagation vs React 18 concurrent rendering boundaries

Question

Integration boundaryRemix v2 loaders execute on the server and pass data to route components via useLoaderData, while React 18's concurrent renderer introduces use() for reading promises inside components and reorders work across suspense boundaries. The two systems have different assumptions about when data becomes available and how component trees suspend.GoalDetermine whether a Remix route component can safely read loader data through useLoaderData while a sibling subtree suspends on a promise consumed via React's use(), without causing hydration mismatches or duplicate loader execution.Constraints and uncertaintyRemix documentation does not explicitly state which React 18 concurrent features are supported or tested.Loader data flows through props internally, not React context, so timing relative to concurrent work is unclear.Error boundaries in Remix and React have different propagation rules; mixing them may surface edge cases.QuestionsDoes Remix's server render wait for all use() promises in the tree before streaming HTML, or can a suspended sibling delay the loader data delivered to other routes?When a route uses useLoaderData and a nested component calls use(promise), what is the expected hydration order on the client?Are there documented patterns or configuration flags to opt a route tree out of concurrent rendering while keeping React 18 for the rest of the app?

Tasadduq Burney · Answer

Integration boundaryA Remix route component can read loader data via useLoaderData while a sibling subtree suspends on a promise consumed through React's use() without inherently causing hydration mismatches or duplicate loader execution, because server-side loaders complete before HTML streams to the client and useLoaderData data is available immediately after mount regardless of sibling suspension.Likely explanationRemix v2 loaders execute on the server and finish before any HTML is streamed; the resulting data is embedded in the response and available to useLoaderData as soon as the client mounts.React 18's concurrent renderer may suspend a component tree that calls use(promise) while the rest of the tree continues rendering; this suspension does not retroactively block loader data delivery to other routes.Hydration on the client can show a brief UI shift if the suspended promise resolves after mount, because the initial HTML reflects loader data but subsequent use()-driven updates re-render sibling components.Confirmed factsThere is no official Remix configuration flag to opt a route tree out of React 18 concurrent rendering; the framework always runs on React 18.Remix's streaming HTML does not wait for any use() promises; assuming otherwise can lead to unexpected UI latency.Client-side navigation may re-fetch loaders, potentially causing duplicate data fetching if not handled with useNavigation.To verify the behavior in your app, open the browser devtools, inspect the initial HTML for loader data presence, then use React DevTools to confirm whether a sibling component suspends via use(). Check the console for warnings about duplicate loader execution or "React cannot find the root".Missing diagnostic detail: Does the suspending sibling component share the same route parent as the useLoaderData call, or is it in a different route tree? This affects whether client-side navigation re-fetches the loader and whether error boundary propagation differs.

Remix loader data propagation vs React 18 concurrent rendering boundaries

Integration boundary

Goal

Constraints and uncertainty

Questions

1 answer

Integration boundary

Likely explanation

Confirmed facts

Your perspective belongs here.

0 question comments