Framer Motion layout and Presence with React 18 concurrent rendering and SSR

Answer to the exact question

1. Presence placeholder on the server does not guarantee identical DOM node count or key mapping after hydration. The placeholder is rendered as static markup and hydration will only succeed if the client’s first render produces the same tree, keys, and node count as the server output. React 18’s concurrent commits affect only updates after hydration; the initial reconciliation follows the same rules as React 17.

2. Measurement timing for layout animations occurs inside Framer Motion’s isomorphic useLayoutEffect. A concurrent render that is interrupted before it commits will not run this effect, so no measurement happens for that intermediate tree. When the render finally commits, measurement runs once on the committed DOM, not on any discarded intermediate frames.

3. Reduced‑motion preference during SSR cannot be detected with window.matchMedia because window is undefined on the server. The usual safe pattern is to render with a neutral default (e.g., animations enabled) and then apply the user’s preference in a client‑only effect or via a server‑side flag that is passed to the page.

Confirmed facts (from library architecture)

• AnimatePresence renders exiting children as static markup on the server; this markup is preserved until the exit animation finishes on the client.
• The isomorphic layout effect used for layout animations falls back to useEffect on the server to avoid React warnings, but it still only runs after the DOM is committed on the client.
• React 18’s startTransition and other concurrent features affect only updates that occur after hydration; the initial hydration step follows the same reconciliation rules as React 17.
• Reduced‑motion detection must be deferred to the client; any server‑side logic that changes the component tree based on matchMedia will break hydration.

Practical steps for this scenario

1. Ensure that the component tree rendered by AnimatePresence is identical on the server and the client, including keys and the set of children that may be conditionally rendered. If you need to vary the tree based on user preference, move that logic into a client‑only effect or use a server‑side flag that is passed as a prop.
2. Wrap any state updates that trigger layout animations in startTransition only if you want them to be deferred. Remember that the layout effect will not run until the update is committed.
3. For reduced‑motion, add a useEffect on the client that reads window.matchMedia('(prefers-reduced-motion: reduce)') and updates a MotionConfig or local state accordingly. Do not let this effect change the component tree that was rendered on the server.
4. Test hydration by inspecting the server‑rendered HTML and the first client render. Enable React dev‑tools’ StrictMode and watch for hydration warnings. If a warning appears, the tree differs and you need to adjust the server or client rendering logic.
5. To debug measurement timing, add a console log inside a motion component’s layout effect and trigger a concurrent update (e.g., using startTransition). Verify that the log appears only after the final committed render.

Missing diagnostic detail that could change the recommendation

Do you currently set any AnimatePresence child keys or component types based on a value that is only available on the client (e.g., reading window or a cookie during the first render)? If so, that difference would cause a hydration mismatch and would require moving that logic out of the initial render.