Member-only story

ADVANCED ZUSTAND “4”, Slices Pattern & Scalable Store Architecture

How can we organize Zustand in big projects?

--

Press enter or click to view image in full size

Why Scalable Store Architecture?

When we first learn Zustand, we create a store using only 1 create() function. But when the project grows monolithic store approach gets worse.

First, let’s check an example of a big monolithic store problem:

// ■ BAD: Big monolithic store
const useAppStore = create<AppState>((set, get) => ({
// Auth State
  user: null,
  isAuthenticated: false,
  login: async (email, password) => { /* ... */ },
  logout: () => { /* ... */ },
  // Cart State
  items: [],
  totalPrice: 0,
  addItem: (item) => { /* ... */ },
  removeItem: (id) => { /* ... */ },
  // UI State
  theme: 'light',
  sidebarOpen: false,
  toggleTheme: () => { /* ... */ },
  // ... 50+ more actions
}));

Problems of this approach:

• File size: A single file can contain thousands of lines of code
• Testing difficulty: To test a feature, you need to mock the entire store.
• Teamwork: Multiple developers working on the same file = merge conflict
• Re-rendering issue: When the authentication changes, card components are unnecessarily re-rendered.