Suggest an editImprove this articleRefine the answer for “What drawbacks does a centralized store have?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)A **centralized store** makes an application's architecture more complex, adds cognitive load, and carries risks tied to global state, lazy-loading, SSR, and performance. **Key point:** for small applications a store is often overkill - you can get by with props/emits, provide/inject, or composables.Shown above the full answer for quick recall.Answer (EN)Image## The main drawbacks of a centralized store --- ### 1. **A more complex architecture** Once a store appears, the architecture becomes: - more complex - more layered - less obvious to newcomers You have to think about: - what state should be global? - what should be local? - where should business logic go? If you make the store too "fat," the application becomes hard to maintain. --- ### 2. **Extra cognitive load** The developer has to understand: - how the store works - how actions, state, and getters relate to each other - how data flows through the application For small applications this is **unnecessary complexity**. --- ### 3. **Being global is a risk** Global state: - lives for the whole session - is available to everything - can be changed incorrectly (if the architecture is violated) - can easily "overload" memory if you forget to clear data This leads to: - hard-to-trace bugs - state pollution - SSR problems (if the store isn't reset) --- ### 4. **Difficulties with lazy-loading** If the application is modular, store modules need to be connected lazily and correctly. An incorrect configuration leads to difficulties splitting the code. This is especially sensitive in Vuex. --- ### 5. **Overkill for small applications** A simple SPA can get by with: - props / emits - provide/inject - composables (Composition API) A store can be: - "using a cannon to kill a fly" - harder to read - harder to maintain than simpler solutions --- ### 6. **A store can turn into a "monolithic dumping ground"** A common mistake: - putting everything into one module - letting the store grow to hundreds of lines - mixing logic together - making it hard to tell what's responsible for what This makes the application less scalable. --- ### 7. **A store complicates SSR and hydration** Especially Vuex: You need to: - create a separate store for each request - avoid global singletons - watch for leaks Pinia handles this better, but the nuances are still there. --- ### 8. **Performance overhead** Every change to global state can trigger: - multiple re-renders - cascading component updates With an incorrect architecture, this leads to lag. --- ## Additional nuances #### Harder to test components If a component depends heavily on the store. #### You need to think about splitting modules Otherwise the store becomes hard to manage. #### The data flow isn't always obvious Especially in large projects with a blurry line between "global" and "local."For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.