What goes in global state in 2026
What belongs in Redux, URL state, server cache, and local state in modern React apps
As a senior developer I’ve seen many developers over-engineering the front-end system and putting too many things in Redux (or Zustand) but after years using Next.js, React Query, context providers and URL parameters, I have a clear vision on what goes and what does not go into global state, there is also a bit of server side rendering.
This is still a problem in the front-end because we don’t see clearly the difference between app state and server state, to give you an example in a social media style page app state can be the posts that you’re actually interacting with and pressing likes and server state are the new posts that are added in the meantime, we need to have a clear picture of what the user is interacting with if we don’t want them to make an update on the wrong post, or see an outdated number of likes because of the wrong cache or offline mode. When new posts come in the feed we need to implement techniques to sync with the app state taking into account a sync strategy: optimistic updates, handling race conditions, and sometimes offline queues so interactions are not lost or applied to the wrong entity.
By adding too much to the global state we’re increasing the cost in several ways: rerendering too much, having stale data that is not synced with the server source of truth, and increasing the difficulty to test components. The smaller the state, the less we need to worry about these things, I’ve seen way too many times a parent React component that rerenders on every interaction every single child component because it is subscribed to too many store updates. There are mechanisms to prevent this, like React memoisation, split slices…
First we need to break down 4 different types of state:
- Server state: TanStack Query, React Query, Server side components and anything fetched from a REST API.
- URL state: query, path, filters, pagination, selected tab, shareable views
- UI state: modals/drawers open, themes, sidebars
- App state: Shopping carts, Draft composition, optimistic updates, offline queues.
What should never go in a global state:
- Controlled input value on every keystroke
- Page content that barely changes over time (blog posts)
- This object that I need in the next page so I’m going to save it in the state so everything seems like a single page application.
For example in a shopping website, the cart needs to be global as is shared across multiple components and pages, needs to be updated from the server regularly (server is the source of truth to keep prices and discounts real) Product details doesn’t need to be stored in the global state, server side rendering takes care of caching, and pagination, filtering and search are URL properties, there is no need to over complicate things here.
In a blog the articles need to be server side cached for SEO and speed, with optimistic updates on comments etc.
It is very useful to take this into consideration when reviewing a pull request, sometimes we don’t stop to think if the use of Redux is necessary to store the list pagination state or some terms and conditions text that we need in several places. A document in the repo for developers to come back to when making a decision is also a good idea.
In conclusion: default to local state and server cache (React Query, RSC, SSR where it fits). Use global state only when several components or pages share the same piece of data
If you liked posts like this you can visit my website to read more articles: raypoly.netlify.app/blog