DEV Community: Ramon Polidura

What goes in global state in 2026

Ramon Polidura — Sun, 05 Jul 2026 11:21:42 +0000

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.

Here is a little diagram to make a decision:

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 this post, you can find more content on my personal website: https://raypoly.netlify.app/blog

Thank you for reading

How to organise a complex React project

Ramon Polidura — Sun, 24 May 2026 11:21:40 +0000

When it comes to starting a new project that you know is going to be big, a sound file structure is a must to nail in the first setup and you as a senior developer need to set up the file system so your team knows how to develop every feature.

In this article I’m going to go through 3 examples: e-commerce, blog, and social media. Indicating which file structure is best for them. This is my opinion and I haven’t asked ChatGPT to write this for me so take it with a pinch of salt and use your own judgement. By the end you’ll know: folder layout, what goes in Redux, how e-commerce / blog / social differ.

The first and most important advice that I want to give you is that you don’t use the frequently messy: pages, services, css, components, hooks, store… structure, I know you’ve used it many times in the past but it is crucial that you structure with these 2 big ideas in mind: features and shared code. Features indicate what the website does, cart, product list, checkout for e-commerce and blog and users for a blog, and social feed and post and user wall for a social media site. After separating the main features you want to expose what is shared within the app: components, utils, api, config. After that you want to have misc folders: types, store and assets.

If you’re using a framework like Next.js or React Native you will have a handy app folder for your url structure, this is very useful to have the page components grouped by url, but you should still use the features structure. What you don’t want to have in the app folder is shared components, and code belonging to the state. Pages should read like a table of contents 10 to 30 lines that import from the features folder. It’s a good place to have the server side file structure but you should keep the reusable functions in the shared folder (making sure these are server side functions only).

A good folder structure for a feature

a components folder for shared components within the feature only, and the same vibe for hooks, types, tests and api folders, but remember to move to the shared folder functions that are used across several features.

A good folder structure for the shared folder can be

ui/ where your atomic components live: buttons, headings, cards… but specific feature components do not: add to cart button, number of likes badge, user card…
libs/ where your plain functions live, single file for each and if you want add folder for all the tests or have them near your functions.
api/ where your API calls live, these are the lowest level api calls live, the GETs and POSTs that just receive the parameters to send and return formatted or ready to be consumed data. These functions are not to be confused with the data layer api functions which make use of a server side cache and can do data manipulation, these should be the ones communicating with that (GraphQL…). These functions should be in charge of the auth headers and error handling. Do not put the server side functions: getUserByID or checkout, they should live in the features folder.
hooks/ useMediaQuery, useDebounce, useLocalStorage. Truly global logic. Tests can live in a common folder or with each hook.
types/ Only global types: User, Product, ApiError. Feature types should live within each feature: CheckoutError, ProductToBuy…
config/ and constants/ files that use the process.env logic, never store actual API keys here.
styles/ themes, global.css, mixins, breakpoints, variables. Component CSS should live in the features folder.
public/ for files accessed via an absolute url
assets/ for files imported in the code, like SVGs

State management

A good folder structure if using Redux can be to add a state/ folder to the project with an index file, a rootReducer and hook files and then having .slice.ts .selectors.ts and .types.ts for each feature. These files get wired together in the state/ folder’s files. You should also add a ui state slice for things like modal opened, side drawer, themes…

What a senior developer should know is what goes and doesn’t go into the state, when we have social media posts that need to be kept in the state for backwards and forwards navigation and like and comment, we do need to keep them in a global state, when we have a blog post that doesn’t have any interaction we should use server side rendering and not store it in the state. We should also not store the value of an input and update it on every character entered.

Another good practice is to put cross-cutting Redux middleware and listeners in a central store/ (or shared/store/) layer, and keep feature folders focused on slices, selectors, and UI, not one-off side effects scattered across components.

Different examples can be found on my personal blog:

https://raypoly.netlify.app/blog/howToOrganiseAComplexReactProject

I hope you’ve liked this article and let’s see each other again on the nets.

I created a page with megadrive games #retro

Ramon Polidura — Fri, 19 Jun 2020 16:45:08 +0000

https://ramonpoli.github.io/mega-drive-games/

A rotating text wheel

Ramon Polidura — Wed, 03 Jun 2020 15:37:16 +0000

Here you can find a project I just made today for a personal page that I'm building at the moment.