state-management

Frontend state location depends on classifying the data as server, client UI, URL, or persistent state, then applying ownership defaults: start local, lift only when needed, use Context for tree-scoped sharing, and use a store for fine-grained updates across many consumers.

Filter, sort, and page state belongs in the URL when the view should be reproducible via a shareable link and navigation history, treating the URL as a state container to enforce deep-linking and proper back-button behavior.

Server state in a general-purpose store causes stale UI because it bypasses proper cache doctrine and invalidation rules, leading to duplicated sources of truth and incorrect optimistic updates instead of treating server data as a cache.

To stop prop-drilling without premature globalization, lift state only when needed and use Context exclusively for real tree-scoped sharing, ensuring a single source of truth without misusing global stores for local UI data.

You should avoid storing derived state when it can be calculated on the fly, as storing it creates a duplicated source of truth that risks becoming stale and requires unnecessary synchronization with the original data.

Yes, this approach works by classifying state by kind with appropriate lifetimes and invalidation rules, explicitly separating server-cached data governed by cache doctrine from general-purpose client UI stores to prevent architectural anti-patterns.