[Deep Dive #29] Override Registry - discussion
Deep Dive #29 argues that once you allow one override, overrides stop being a one-off fix and become a governed contract: what path is overridden, why, and what audit posture it implies.
If you use overrides, do you keep them ad-hoc near the route, or do you actually maintain a central registry/atlas like the post suggests? Do you attach audit layouts/postures to overrides (so the override is visible from the surface), or is that too much ceremony? How do you keep overrides from becoming a dumping ground for “we’ll fix routing later”?
Comments (10)
Back to latestA registry is the only way overrides don’t turn into folklore. Otherwise you’re debugging “why is this route special” forever.
The post’s key line is “a registry is a contract”. That’s right.
We treat every override like an API: reason, implied layout posture, and a visible marker in the route shell.
Related: Routing and Navigation and the global contract posture in Route State Stored in Global Context.
We ended up with a tiny registry surface that we render in internal builds:
tsx
const registry = [
{ path: '/atlas/admin', layout: 'audit', reason: 'contract governance' },
{ path: '/atlas/[slug]/audit', layout: 'audit', reason: 'surface evidence' },
];
export function RegistryMarker({ path }: { path: string }) {
const entry = registry.find((e) => e.path === path);
return <div data-override={entry ? 'yes' : 'no'} data-layout={entry?.layout ?? 'default'} />;
}Counterpoint: central registries can become a bottleneck where every team has to negotiate to ship a route change.
We kept the registry, but we allowed per-feature ownership as long as the override still had a reason + rendered marker.
That seems like the right compromise.
My fear is more “override as escape hatch” where nobody ever pays down the routing debt because the override keeps the app ‘working’.
Yep. If overrides aren’t visible from the surface, they’ll accumulate silently.
We used audit layouts exactly like the post suggests and it helped migrations.
When a route is overridden into an audit posture, it’s a signal that it’s “special on purpose”, not special by accident.
This also helped with code review: you can ask “what override are we relying on” instead of hunting through file routing definitions.
The moment we rendered registryCount, people started treating overrides as a budget.
We had a bug where a route unexpectedly landed in an audit layout after a refactor.
Seeing data-layout='audit' in a screenshot made the “why is this page weird” question answer itself.
Overrides are fine as long as you treat them like contracts.
What scares me is overrides that exist only as code comments, not as route-visible evidence.
If your override doesn’t have a reason string, it’s not an override — it’s a hack that survived long enough to become tradition.
Registry + audit posture is basically “make routing debt visible”.
If it’s visible, it can be owned. If it’s invisible, it will metastasize.