remix

Continuation of #11562 See the deployed preview: https://remix-3-guides.fly.dev/docs/ I pulled this out into a separate PR because I decided to go a bit of a different architectural direction. After trying to write docs in JSX and finding it incredibly difficult, I switched to markdown + a custom directive for loading in Remix ``s anytime I need dynamic examples or any sort of rich component. Other than that, the content is still oriented around the chapters set in #11562, and I'm just continually working through them. Chapters that have been written and reviewed by me, a human: ✅ Start Here

The scheduler's cascading update guard used one per-turn counter for all component updates. That meant a large batch of legitimate hydration/update work could look like an infinite loop and stop later components from becoming interactive. This keeps the performance signal while making the hard guard more precise. The runtime now warns once per event-loop turn when aggregate cascading component updates cross the threshold, but only dispatches the infinite-loop error when the same component instance repeatedly updates itself. Closes #11222. Adds component-name/count diagnostics to the aggregate warning and hard error Tracks the hard error limit per component instance instead of globally Preserves the existing protection for loops during render Adds a regression for 60 component instances updating in the same event-loop turn

Context We're building a social feed (post cards with reactions, comments, share buttons) using . Each post uses several components. With 20 posts on the initial page, we had 92+ hydration regions and hit in the scheduler. The error fired and left most components unhydrated. No actual infinite loop — just many components hydrating in the same microtask turn. Minimal reproduction Expected: All 60 buttons hydrate and are interactive. Actual: Hydration stops at 50. Buttons 51-60 render as static HTML but clicks do nothing. Console shows . Can provide a StackBlitz if helpful. The limit is actually useful — but the DX needs work The 50 limit pushed us to optimize. We reduced from 92 to 16 hydration regions by: Converting image/avatar components from to server components with CSS fallbacks Moving share button logic from to event delegation ( attributes + global click handler) Reducing initial SSR page size from 20 to 5 posts (viewport-only, infinite scroll loads more) The guard caught a real performance issue. But the experience of discovering and diagnosing it was rough: 1. The error message is opaque. gives no component names, no counts, and no indication of whether you're at 51 or 5000. We had to read the scheduler source to understand what was happening. 2. It errors instead of warning. Hitting 50 kills hydration entirely. A at 50 would give the same signal without breaking the page. Teams would see it, investigate, and optimize — without the "why is nothing interactive?" panic. 3. No way to configure it. We had to use a pnpm patch. Something like would let teams tune for their use case. 4. Per-component tracking for the hard error. 51 different components each updating once isn't a loop. One component updating 51 times is. The hard error (infinite loop detection) would be more accurate as a per-component counter, while the global counter could remain as a warning/optimization signal. What we patched locally We ended up patching the scheduler to get better diagnostics: Warns at 50 with a component breakdown: Errors at 200** with the same breakdown in the error message Resets the warn flag each event loop turn This turned a confusing breakage into an actionable optimization signal. Proposed patch Here's the patch we're running locally via pnpm . Happy to open a PR if this direction is useful. Changes to : Reset warn flag alongside the counter: Warn at 50 with component breakdown, error at 200 with the same: Summary of suggestions Environment Guard introduced in PR #11060 (commit )