One nav, two use cases
Two parallel nav components got merged into a single component with anchor-aware routing. Why duplicates always lose.
2026-04-29 · 3 min read
For about a week the portfolio had two navigation bars. Global Nav on every route. Internal nav inside the home layout component. Looked identical. Were not. Different hover transitions. Different link colors. Notes link in one and not the other. I had been editing both and forgetting which.
How this happens
Home wanted anchor links to scroll to sections. Subpages wanted full-route links. I solved it by giving each layout its own nav. Fine for a sprint. Poison for a portfolio that gets edited every other day. Every visual tweak had to land in two places. Any tweak that landed in only one created visible drift between routes.
The merge
Single Nav component. A routing function picks the target based on the current path. On home, anchors. Anywhere else, full routes back to home with the hash appended. Active state computed against the path, not the link. Hidden on demo and prototype routes that have their own chrome. One file, one set of styles, one source of truth.
The principle
When you find yourself with two components that look the same and behave almost the same, do not split them by the difference. Merge them and parameterize the difference. Duplicates look cheaper for one sprint. Across ten sprints they are the most expensive thing in the codebase. Two parallel implementations of the same UI primitive is a refactor I owe the project before the next feature lands.
Reach out: jason@theft.studio