Cmd+K looks like a fuzzy-search modal you bolt on at the end. Build it that way and it immediately drifts out of sync with the buttons and menus it duplicates. The real thing is a command registry: one typed source of truth for everything the app can do, feeding the palette, the shortcuts, and the menus at once.
Dark mode looks like a class you toggle. Then you meet the flash of the wrong theme on load, colors that drift because every component hardcodes its own, and a theme context that re-renders the whole app. Theming done right is tokens, one switch point, and a boundary — and it barely touches React at all.
There's a particular panic I keep running into: a component re-rendered, someone saw it in the profiler, and now they're tearing the architecture apart to stop it. But rendering isn't React's flaw — it's the whole idea. The word you want is optimize, not minimize, and the difference decides whether your app stays maintainable.
Most analytics code is a scatter of track('button_click') calls with drifting names, mystery payloads, and three vendor SDKs called inline. Analytics is a cross-cutting concern, and it belongs in a layer with a typed event catalog — not smeared through your components. Here's how I structure it.
Feature flags decouple deploy from release, and that's genuinely powerful. But every flag is a fork in your code, forks multiply, and the ones nobody deletes quietly become the most dangerous debt in the codebase. The architecture isn't the flag — it's how you evaluate, type, and eventually kill it.
An event bus feels like the cure for prop drilling and tangled dependencies — anything can talk to anything, and nothing is wired together. That's exactly the problem. It doesn't remove the coupling, it hides it. Here's where a bus genuinely helps and where it quietly turns your app into action-at-a-distance.
isLoading, isError, isSuccess, isEditing — five booleans give you thirty-two combinations, and most of them are impossible states your code still has to survive. A state machine makes the impossible ones unrepresentable. Here's when to hand-roll one and when to reach for XState.
The instinct is to snapshot your whole state on every change and step backward through the copies. It works until it doesn't. A history of reversible commands scales further, describes what actually changed, and survives contact with a server. Here's how I build undo/redo that doesn't fall apart.
Optimistic UI is a small lie: you show the result before the server confirms it. Done right, the app feels instant. Done wrong, the UI quietly tells the user something that never happened. The difference is entirely in how you roll back.
The same customer shows up in a list, a detail page, and a header badge — three copies of one truth you don't own. Edit one and the others go stale. Here's when to normalize server data into one source of truth, when the query cache is enough, and how to invalidate without nuking everything.