Escape Hatches - discussion (2023-05-06)
Escape hatches always feel like a maturity test: do you pretend everything is declarative, or do you admit there are imperative edges and make them contract-driven and observable? I like the article when it leads to healthier boundaries instead of secret tunnels.
What escape hatches do you allow in your UI layer (refs, layout measurement, imperative focus/scroll)? Do you wrap imperative actions behind a contract boundary (actions + reason + evidence), or call DOM APIs directly? How do you make escape hatches visible in review so they don't become the default solution?
Comments (12)
Back to latestImperative focus and scroll are fine.
Imperative business logic is not.
We require a reason string for imperative actions and we log it as tips lines:
txt
[tips] action=focus reason=cmdKShortcut target=globalSearch
[tips] action=scroll reason=routeEnter target=topIt keeps the escape hatch narratable instead of magical.
Concrete alternative: never expose refs, only expose actions.
We found actions are reviewable and composable; refs turn into little private APIs that drift.
Agree. Ref methods can be fine, but they should behave like actions: named, reasoned, and observable.
Long-form: escape hatches are safe when they don't own identity.
Measurement + interop is fine. The moment the escape hatch starts deciding which record is selected or which route is active, it's smuggling state outside the contract surface.
Docs tie-in: the best pattern is to keep posture explicit and imperative edges small.
Related: Core Concepts and Routing and Navigation.
Short take: if you need an escape hatch twice, it probably deserves a named boundary.
We had a third-party editor widget. The escape hatch was imperative updates.
The difference-maker was logging the imperative edges and rendering evidence that the widget was in sync with the route doc.
Make them visible. If escape hatches are invisible, they spread.
We have a checklist: imperative action must (1) accept a reason, (2) be replay-safe, (3) render evidence on outcome.
If it can't meet the checklist, we redesign the boundary instead.
Takeaway: escape hatches are fine as long as they stay as edges with a story, not as a second architecture.
Actions + reasons + evidence keeps them honest.
If you can't explain it in one tips line, it's too big to be an escape hatch.
I like treating escape hatches as temporary until proven otherwise.
If the edge stays around, promote it to a contract surface with ownership and tests.