SwapReusable Interaction Workflows With Swap Handlers
As a project grows, the same interaction pattern starts showing up in more than one place.
Maybe several screens all save something, refresh a list, and show confirmation. Maybe several routes need the same event trigger and the same summary refresh. At first, copying the pattern feels efficient. After the third or fourth variation, it starts to feel brittle.
That is the point where handlers become useful.
What a handler should own
A good handler owns a repeated interaction workflow, not a random bag of helper methods.
That usually means it packages things like:
- a predictable response pattern,
- a shared update sequence,
- common success or failure behavior,
- repetitive interaction-level wiring.
It should represent a meaningful UI workflow that happens in more than one place.
What a handler should not become
The risk is turning handlers into a second hidden controller layer. When that happens, controller intent gets harder to follow because the real behavior is split across too many abstractions.
If a handler hides the workflow rather than clarifying it, it is too big or too generic.
A good smell for extracting one
Reach for a handler when you notice all of these at once:
- the same response shape appears in multiple actions,
- the workflow is conceptually the same across those actions,
- keeping it duplicated would make future changes risky.
That is a stronger reason than simply wanting fewer lines of controller code.
Keep the controller readable
The best outcome is that the controller still reads like the feature entry point while the handler owns the repeated interaction mechanics.
In other words, the controller should still make it obvious:
- what action happened,
- what business decision was made,
- which workflow is being invoked.