[Deep Dive #43] Power Pattern Arsenal - discussion
Deep Dive #43 reads like a tour of the Patterns Library: it treats common failure modes as reusable power patterns you can intentionally adopt (and then standardize).
It calls out entries like Context Whirlpool, Duplicate Fetching, Effect-Driven UI, Hidden Side Effects, Phantom State, and the classic Prop Drilling Marathon.
Which Patterns Library entries do you treat as 'allowed' (and document), vs something you try to eliminate? Do you prefer a small number of huge patterns that everyone recognizes, or lots of tiny patterns that feel precise but fragment the vocabulary? How do you keep 'power patterns' from becoming an excuse to stop rendering evidence (lanes, versions, posture keys)?
Comments (10)
Back to latestThe Patterns Library being first-class is the best part of this blog series. People already do these things; naming them makes code review faster.
Related: Patterns Library.
Context Whirlpool is real. If your app already has 6 contexts, the seventh doesn't feel like a big deal… until it is.
I like the framing of making it intentional and then adding a signal so you can see the whirlpool depth.
Duplicate Fetching is not always a bug. It's sometimes a posture: redundancy for resilience and independent screens.
If you choose it, the important part is making fetch lanes visible so you can tell what's duplicating and why.
Effect-Driven UI sounds cursed, but it is how many teams actually ship features quickly.
The best mitigation is consistency: if UI is effect-driven, standardize the effect names and render a small evidence panel.
Hidden Side Effects should probably be treated like a library entry with a giant warning label… but I get why the deep dive includes it.
If you are going to hide them, at least surface a 'side-effect budget' counter somewhere.
Prop Drilling Marathon is my favorite name in the library because it makes the tradeoff obvious: you pay in legs (props) or you pay in whirlpools (context).
Having both in one reference is useful because the 'fix' is often just moving the cost around.
The only ones we try to actively eliminate are Hidden Side Effects and Phantom State.
Everything else we treat as "allowed" as long as the lane is named and the evidence renders somewhere.
We turned the "side-effect budget" idea into something painfully literal: a counter that increments every time an effect writes into shared state. It's not about stopping it. It's about making it obvious when one screen is doing 14 invisible writes and another does 2.
tsx
import { useFlowEffect, useLiveState } from "react";
function useEffectBudget(routeId: string) {
const ledger = useLiveState(`budget:${routeId}`, { writes: 0 });
function recordWrite() { ledger.write("writes", ledger.read("writes") + 1); }
return { ledger, recordWrite };
}
export function RouteShell({ routeId, children }: { routeId: string; children: any }) {
const budget = useEffectBudget(routeId);
useFlowEffect(() => { /* a shared write */ budget.recordWrite(); }, [routeId]);
return <div data-effect-writes={budget.ledger.read("writes")}>{children}</div>;
}Docs tie-in: State Hooks (the "reveal behavior" principle is what makes this palatable).
My worry: if you name 30 patterns, people stop thinking and just "activate the right label".
I'd rather have 5 patterns, enforced hard, than an encyclopedia nobody can remember.
I read it differently: the library is mostly a shared vocabulary for code review.
The enforcement is still about route posture + evidence, not about memorizing names.
Fair. Maybe the compromise is: big library, but only a small "equipped" subset per product.
That would make the vocabulary stable without forcing every team to learn everything.
I’d love to see the Patterns Library call out which patterns are "routing tools" vs "composition tools".
Right now it’s easy to accidentally treat a routing posture like a local refactor and then wonder why the surface drifted.