Three Kinds of State, Three Different Tools
Most frontend complexity comes from treating all state identically. Server state is data owned elsewhere, replicated into the browser, and always potentially stale — it needs caching, revalidation, and background refresh, which is what query libraries provide. Client state is genuinely owned by the interface: form drafts, selections, modal visibility. URL state is the subset that should survive a refresh and be shareable.
Putting server data into a global client store means reimplementing cache invalidation, request deduplication, and retry logic by hand. Putting filter state into a client store instead of the URL means the view cannot be shared or bookmarked. Both mistakes are structural rather than stylistic.
State Across Micro-Frontends
When independently deployed applications share a page, shared mutable state becomes a distributed systems problem. Shared state should be minimal and explicitly contracted — authentication context, tenant, locale, theme — exposed through a versioned interface rather than a shared store object that any application can mutate.
- Communicate between applications with events or a versioned host contract.
- Never share a mutable store instance across independently deployed bundles.
- Keep navigation state in the URL so the router remains the source of truth.
- Version the shared contract so applications can deploy on independent schedules.
Optimistic Updates and Reconciliation
Responsive interfaces apply changes locally before the server confirms them. That requires a defined rollback path, a strategy for conflicting concurrent edits, and a way to surface eventual failure without silently discarding user work. Where multiple users edit simultaneously, last-write-wins is a decision, not a default — and often the wrong one for enterprise workflows where an overwritten field is a business error.
Keeping mutations narrow, invalidating precisely the affected queries, and reconciling against the server response rather than assuming success keeps optimistic UI honest.
Observability in the Browser
Distributed frontends need the same operational visibility as backend services: structured client-side error reporting with source maps, a correlation identifier propagated into backend traces, and instrumentation of the interactions that matter commercially. Without correlation, a frontend failure and its backend cause are investigated as two unrelated incidents.