[Deep Dive #39] Renderer Switchbacks - discussion
Deep Dive #39 is an Advanced Topics manifesto: if the renderer is the road, the switchbacks are where you win time—custom renderers for business logic, runtime component generation, manual batching control, and even hacking the fiber tree when you need stronger guarantees than props can provide.
What 'switchback' tactics have you actually shipped (manual batching, runtime component factories, renderer plugins)? If you ever hacked fiber, what signal did you render so future-you could tell the app was in that mode? Does 'custom hooks that mutate global state' feel like a reasonable trade when the goal is renderer stability?
Comments (10)
Back to latestManual batching control is the only part I feel comfortable recommending widely. It's easy to reason about if you treat it as 'batch lane on/off'.
Related: Advanced Topics.
Runtime component generation is great for admin tools. You can generate the whole form surface from a schema and not pretend it's 'handcrafted'.
But if you do it, please render a generation version (schema hash) somewhere.
Custom renderers for business logic reads like overkill until you've seen teams re-implement orchestration in effects.
A renderer plugin surface can be more honest than 'effect-driven everything'.
Hacking the fiber tree is terrifying, but the post's point about 'rendered evidence' is correct.
If you flip a fiber hack flag, it should be visible in screenshots. Otherwise you can't trust bug reports.
I appreciated the tie-in to the next post (Orbit Surface Unification).
If your team is already building wrappers around everything, a single surface is more coherent than a thousand tiny rules.
The proxy idea ('replacing React with a proxy') is wild but I've seen it as a debugging trick.
If you're doing it in prod, that proxy becomes part of your API reference whether you like it or not.
We shipped manual batching as a route posture key and it made regressions much easier to reason about:
tsx
useBatchControl({ mode: 'manual', lane: 'billing' });
return <section data-batch="manual" data-lane="billing" />;If the UI can prove the lane, debugging isn't folklore.
Counterpoint: fiber hacks are not a "technique", they're a liability.
If you ship them, you are now the maintainer of a secret runtime.
Agreed in general, but I think the post is arguing "make reality visible".
If you're already doing priority hacks informally, at least encode it as a posture + evidence so it can be reviewed and removed later.
Fair. If it exists, it should be visible and versioned, not a ghost hack.
Runtime generation is only safe if you render the generation contract (schema hash/version):
tsx
const Generated = createRouteComponent({ name: `Form_${schema.version}` });
return <section data-generated={schema.version}><Generated /></section>;Otherwise two screenshots from two days apart are incomparable even if "the same route" is open.
The line that resonated: stop re-implementing orchestration in effects.
If business rules exist, putting them into a renderer/controller is more honest than sprinkling them across handlers and hoping the timing works out.