Before shipping it, separate protocol facts, product promises, and operating cost. Mixing those layers produces confident but incorrect decisions. navigator.onLine only indicates an interface, not server or peer reachability. Feature availability combines signaling, peer session, storage, and permission facts.
A product loop covers start, wait, cancel, failure, recovery, and re-entry while automation obeys the user’s latest explicit choice. Metrics measure task outcomes rather than button clicks.
The parts that make the design practical
Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.
- Drive controls from capability selectors: history and settings offline, files selectable into a queue, screen sharing requiring a peer, with reason and action beside disabled controls.
- Separate protocol facts, user intent, and automatic recovery; automation may restore facts but never overturn an explicit choice.
- Use explicit capability negotiation so older clients receive an explained fallback instead of a half-working state.
The delivery standard for Offline Feature Gating Based on Capability Instead of a Global Disable is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Keep false assumptions out of production
Prioritize faults that silently preserve false facts: the interface looks recovered while a queue, permission, or counter has diverged. The defect often appears only on the next action.
- Globally disabling the page blocks history and cancel, while allowing input only to toast network error wastes user work.
- Fixing only the UI leaves queues, locks, or expired credentials for the next operation to inherit and fail again.
- User or task IDs in metric labels create high-cardinality cost and leak unnecessary identity into diagnostics.
What the release gate should inspect
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Cut internet, signaling, peer, and local storage separately; verify every control state and ensure queued work executes once after recovery.
- Drive the state machine with reordered, duplicate, and delayed messages, proving stale versions are ignored and explicit stop survives recovery.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.