{
  "id": 12322507,
  "title": "Your Global Store Is a Junk Drawer. Sort State Into Four Boxes First",
  "url": "https://urgent.news/2026/10/06/your-global-store-is-a-junk-drawer-sort-state-into-four-boxes-first",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-06T06:58:08.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/nurrehman/your-global-store-is-a-junk-drawer-sort-state-into-four-boxes-first-nbb"
  },
  "original_language": "en",
  "account": "In today's software development, single global stores are often used to hold all state within an application. However, this approach quickly leads to a messy, hard-to-maintain codebase. The key to structuring state effectively is sorting items into four distinct categories: server state, URL state, local UI state, and persisted state.\n\nServer state consists of data fetched from a backend, such as database information or API responses. It should be treated like a cache, using tools like query libraries with stale-while-revalidate mechanisms rather than being managed directly by reducers. There's no need to hand-write complex state management logic in 2026.\n\nURL state represents data that can be shared through a link, such as search filters, selected tabs, or pagination settings. Query parameters provide an underutilized, free option for persisting this data across page refreshes and enabling deep linking.\n\nLocal UI state pertains to component-specific information that doesn't need to travel across the application. For example, a modal open flag should be managed within the component that uses it, rather than being part of a global store.\n\nPersisted state refers to data that needs to survive a user reload. This includes cached versions of previous sessions and should be stored using mechanisms like localStorage or IndexedDB, with proper hydration plans and expiry strategies.\n\nThe crucial decision rule is to classify each state item into one of these four boxes before considering a global store. If a piece of state doesn't fit neatly into any category, it likely doesn't belong in a shared store in the first place. After sorting, the remaining shared, client-owned state comprises the true purpose of your application's store. By following this simple rule, you can dramatically reduce store bloat and create a cleaner, more maintainable codebase.",
  "summary": "If everything lives in the store, nothing really lives in the store. I have watched senior engineers, people with a decade on their resume, answer \"how do you structure state in a complex app\" by describing one giant global store. Server data, form inputs, a sidebar toggle, a cached auth token, all of it swimming in the same tank like it is 2016 and we are still doing it for the aesthetic. It is…",
  "key_points": [
    "Sort state into four categories: server, URL, local UI, persisted",
    "Server state like cache, use query libraries for stale-while-revalidate",
    "URL state for data shareable through link, use query parameters"
  ],
  "editors_take": "Sorting state into four distinct categories helps developers avoid a messy global store, instead allowing them to maintain a cleaner, more manageable codebase with a clearer understanding of what data belongs.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}