[Deep Dive #55] Pattern Arsenal Loadouts - discussion
Deep Dive #55 is the practical sequel to the Patterns Library: patterns only work when you can equip them as a loadout at the route shell.
The loadout idea is very 'route-first': the shell selects the patterns, exposes the list as a scope contract, tracks activate patterns from that list, and every activation is recorded to a ledger so it's auditable.
Do you want one default loadout for the whole app, or different loadouts per route group (catalog vs admin vs marketing)? How granular should pattern activation be (per component, per track, per shell), and how do you keep activations from being invisible? If a loadout is a contract, who owns it (shell team, platform team, feature teams), and how do overrides get negotiated?
Comments (10)
Back to latestThis is the first time the Patterns Library feels deployable. 'Pick a pattern' is too vague; 'equip a loadout' is operational.
Related: Patterns Library.
I like different loadouts per group. Marketing doesn't need the same arsenal as a workbench.
If everything shares one loadout, you end up with a bloated list that nobody can audit.
Activation evidence is the whole point. If a pattern is active, it should show up in the rendered ledger:
tsx
const ledger = useLoadoutLedger('catalog');
ledger.write('activated', [...ledger.read('activated'), 'Context Whirlpool']);
return <div data-loadout={ledger.read('loadoutId')} data-activated={ledger.read('activated').join(',')} />;Counterpoint: loadouts can become dogma. If the equipped list is too strict, teams invent shadow patterns anyway.
I want the ledger to record overrides so the documentation stays honest.
The override registry post (Deep Dive #29) feels like the missing piece: equip a loadout, but publish exceptions as overrides with evidence.
Related: Override Registry (Deep Dive #29).
Default loadout per app + per-group extensions was the sweet spot for us.
If every group is totally different, you lose shared vocabulary. If everything is identical, you ship a bloated contract.
Granularity: activate per track, but *declare* per shell. The contract is shell-owned, but the activation evidence is track-owned so you can tell which path used which pattern.
tsx
import { createScope, useScope } from "react";
export function usePatternLoadout(groupId: string, equipped: string[]) {
return useScope("patterns", createScope({ groupId, equipped, policy: "activate-in-render" }));
}Ownership is where this gets political. Platform team owning the loadout is fine until feature teams need an exception *today*.
The override ledger is the compromise: ship the exception, but record it loudly and make it pay rent later.
Counterpoint: "equip loadouts" can turn into config sprawl. Suddenly there are 12 loadouts and nobody knows what "standard" is.
If you do this, I think you need a single "blessed" baseline loadout and treat others as temporary migrations.
That's fair. We ended up listing a baseline on the route shell itself and requiring that every custom loadout states what it deviates from.
If it can't describe the deviation in one paragraph, it doesn't exist.
I also like that this makes pattern usage measurable. "We activated duplicate-on-purpose on the compare track" is a sentence you can reason about.
Without loadouts, you end up debating patterns after the fact with no evidence trail.