The standard progression in a frontend codebase is that state gets passed through a few layers, becomes awkward, and someone introduces a global state library. It usually helps for a while and then the store becomes an enormous object holding everything the application has ever fetched, with no clear ownership and no idea when anything is stale. The mistake was earlier: treating all state as one kind of thing.
There are at least four kinds and they want different tools. Server state is data that lives in your database and is temporarily on the client - lists, records, anything fetched. Client state is genuinely local: is this modal open, what has the user typed, which tab is selected. URL state belongs in the address bar: the current page, filters, the selected item. And form state is its own thing, with validation and dirty tracking.
Server state is the majority of what most applications hold, and it is not really state - it is a cache. The questions it raises are caching questions: when does this go stale, what happens if two components need it, how do we refetch after a change, what shows while it loads, what happens when it fails. A data-fetching library that answers those questions is a far better fit than a general-purpose store, and adopting one typically removes most of what was in the global store.
URL state is the one teams most often get wrong, and it costs users directly. If a filtered, sorted, paginated view keeps its state in memory, the user cannot bookmark it, cannot share it, and loses everything on refresh or when they press back. Putting it in query parameters costs almost nothing and makes the browser's own controls work as people expect.
What remains after those two is genuinely small: theme, sidebar collapsed, the current user, a notification queue. That amount of state does not need a large library - the framework's own context mechanism or a lightweight store is sufficient, and choosing a heavy solution for it adds indirection without benefit.
The practical sequence is to start with local state, lift it only when two components genuinely need it, put anything the user would want to bookmark in the URL, and use a data library for anything from the server. Reach for global state only for what is left. Codebases that follow that order rarely end up needing a large state solution at all, which is a better outcome than choosing one well.
