The Hidden Pattern Behind Webhooks, Dark Mode, and Durable Interfaces

Hatched by Warish

Jun 01, 2026

9 min read

2 views

86%

The real problem is not building features, it is making them remember

What makes a system feel intelligent is often not what it can do once, but what it can remember after you stop looking. A webhook that receives a JSON payload, a button that toggles dark mode, and a browser that stores a preference in local storage may look like small, unrelated mechanics. But they all solve the same deeper problem: how do you let a system change in response to an event without forcing the user to repeat themselves?

That is the quiet design challenge behind most modern interfaces. A trigger fires. A state changes. The change should survive the next refresh, the next request, the next session, maybe even the next system altogether. When this works well, software feels responsive and personal. When it fails, everything feels forgetful, brittle, and strangely manual.

The interesting question is not “how do I toggle a theme?” or “how do I receive a webhook?” It is this: how do we design systems that treat user intent as durable state, not temporary behavior?

Events are easy. Persistence is where software becomes trustworthy

A click listener is one of the simplest ideas in programming: something happens, then a function runs. A webhook is the same idea at a larger scale: some external service sends a request, then your endpoint reacts. In both cases, the first move is easy. The challenge is what happens after the reaction.

Think of a light switch in a hotel room versus the electricity grid behind it. The switch is an event. The grid is state. If the hotel only remembered the switch position while you stood there, it would be useless the next morning. The same is true for software. A dark mode toggle that resets on refresh is not really a preference, it is a temporary illusion of preference.

That is why the combination of event handling and state storage matters so much. The click is the decision. The stored key value pair is the memory of that decision. Together they convert a momentary action into a persistent experience.

A responsive interface is not one that reacts quickly. It is one that reacts once and then remembers.

This is the deeper pattern shared by webhooks and UI toggles. A webhook receives a web request with a JSON payload. A dark mode button receives a click and flips a class on the body. In both cases, the system listens for a signal and then transforms that signal into a stateful outcome. The difference between toy code and durable design is not complexity. It is whether the system preserves intent.

CSS variables and local storage are not just tools, they are a philosophy of indirection

The dark mode example looks simple on the surface: define colors with CSS variables, then swap the values when a dark-mode class appears on the body. But what matters is the structure hidden inside that simplicity. The page does not repaint every element manually. It changes a few global variables, and the rest of the site follows.

That is a powerful idea. Instead of telling each component what to be, you define a small number of shared truths and let the interface inherit from them. A background color changes. A text color changes. Everything else updates downstream. This is not just cleaner code. It is a model of good systems thinking: centralize meaning, decentralize effects.

Local storage extends the same philosophy across time. CSS variables let the page respond consistently inside a single render. Local storage lets the page respond consistently across sessions. One is spatial memory, the other is temporal memory. Together they create continuity.

Here is the key insight: users do not experience code. They experience consequences. They do not care whether a theme is implemented through a class toggle, a context provider, or a stored value. They care that when they choose dark mode at 11 p.m., the site respects that choice at 11:01 p.m. after a refresh.

This is why the distinction between selectors, state, handlers, and mount time matters more than it first appears. Selectors locate things. Handlers define reactions. State represents durable information. Mount time is when the system reconstructs reality from what it knows. That sequence is the skeleton of every respectable interface.

If you blur those roles, the code becomes harder to reason about. If you separate them well, the interface starts to feel inevitable.

The deepest interface is not the button, it is the memory model

A theme toggle is usually explained as a UI trick, but it is really a tiny lesson in memory architecture. The button does not contain the theme. The body does not contain the theme in any permanent sense. The browser's storage does not define the theme by itself either. The theme is an agreement among three layers:

The signal: a click or a request arrives.
The state change: a class is toggled, a value is stored or removed.
The reconstruction: on load, the system checks what was remembered and restores it.

This pattern is everywhere once you notice it. A webhook is useful because it lets another system outsource its memory of your event. A browser preference is useful because it lets the application outsource its memory of your choice. Even the humble if statement that checks whether a stored theme exists is doing philosophical work: it decides whether the world should be rebuilt from memory or initialized from default.

That distinction matters because defaults are not neutral. They are assumptions. Memory is a correction to assumption. In a light mode default, dark mode is a request to be remembered differently. In a webhook flow, a JSON payload is a request to be acted on immediately, without waiting for human intervention. In both cases, the system becomes more humane when it can distinguish between what should happen now and what should persist later.

Consider a more concrete example. Imagine an app that lets you choose between metric and imperial units. If the choice only changes the current screen, the app is performing. If it stores the preference and restores it on the next visit, the app is serving. That difference is subtle but enormous. Performance is the illusion of intelligence. Memory is the proof of respect.

The short circuit is a useful metaphor for good design

One particularly elegant detail in the implementation is the use of short circuiting. The theme variable is checked, and only if it exists does the page reapply dark mode. That tiny logical structure captures a broader design principle: do not execute work unless the precondition is real.

This is how robust systems avoid noise. They do not react to everything equally. They establish gates. A webhook endpoint should validate the request before acting on it. A theme loader should verify that a preference exists before restoring it. A UI should change only when the state change is meaningful.

This gives us a useful mental model: good interfaces are full of gates, not guesses.

A gate says, “If this condition is true, then proceed.” A guess says, “I think this is probably fine.” Gates create predictable behavior. Guesses create accidental behavior. That is why the most boring looking line of code, the one that checks whether local storage contains a key, is often the line that prevents the biggest class of bugs.

It also explains why the clean separation between event listeners and state checks matters. The click handler does not need to know everything. It only needs to toggle the class and update storage. The page load logic does not need to know why the user chose dark mode. It only needs to restore it if the preference exists. Each part does one job, and the jobs fit together because they are narrow.

That is the same logic that makes webhooks powerful. A webhook endpoint does not need to know the entire business process. It only needs to recognize a signal and pass it into the right system. The event boundary is the point where responsibility shifts. Good design makes that shift explicit.

A practical framework: signal, state, restore

If you want one framework to carry from this discussion, make it this:

1. Signal

Something happens. A user clicks. A service sends a request. A condition changes.

2. State

The system records the meaningful outcome. A class is toggled. A JSON payload is received. A key value pair is saved or removed.

3. Restore

On the next relevant moment, the system reconstructs the experience from memory. The page reloads. The preference returns. The interface remains coherent.

This framework is useful because it stops you from thinking of interactivity as a pile of one off behaviors. Instead, you start seeing whether every action has a memory path. If not, you may have built a moment, not a system.

Here is an easy test: whenever you add a toggle, ask what should happen after refresh. Whenever you add a webhook, ask what should happen after the payload arrives. Whenever you let a user express preference, ask what should be remembered. If the answer is nothing, the feature may be shallow. If the answer is yes, you have created continuity.

That continuity is what users interpret as quality. It reduces friction, but more importantly, it reduces cognitive load. The user does not need to reassert identity at every visit. The system already knows the shape of the last choice.

Key Takeaways

Separate event from persistence: A click or request is not enough. Decide what must be stored, restored, or forwarded.
Use variables and indirection on purpose: CSS variables and storage keys make systems easier to change because meaning is centralized.
Design for the next load, not just the current action: The real test of a preference is whether it survives refresh, restart, or reentry.
Think in gates, not guesses: Check conditions explicitly before running logic. Short circuiting is a pattern for clarity and reliability.
Treat user choice as durable state: When people choose dark mode, units, layout, or notification settings, they are asking to be remembered.

Building interfaces that remember is a form of respect

The most elegant thing about a dark mode toggle is not that it changes color. It is that the page becomes a participant in your habit. You click once, and the interface carries that intention forward. The same is true of a webhook. It lets one system respect the urgency of another without forcing a human to mediate the exchange.

That is the real connection here: software feels powerful when it turns transient signals into durable relationships. A webhook turns an outside event into an internal action. A stored theme turns a fleeting click into a lasting preference. A class toggle turns a visual state into a reusable abstraction. All three are variations on the same promise: your choice will not be lost in the gap between moments.

Once you see that, you stop thinking of interfaces as surfaces and start thinking of them as memory systems. And that changes how you design everything. You are no longer asking, “What happens when the user clicks?” You are asking, “What should this system remember about that click?”

That is a much better question. It is also the question that separates a feature from a feeling, a reaction from reliability, and a demo from a product people trust.