What drawbacks does a centralized store have?

#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."