The unopinionated principle
When they say that Zustand is "unopinionated", it means the library does not impose a strict way of organizing code, store structure, or application architecture. It gives only tools, not rules for how to use them.
Simple definition
Unopinionated means the library does not dictate exactly how you should write your code, but only provides a minimal API for managing state.
Example in practice
In Redux
Redux is opinionated:
- it requires
actions,reducers,dispatch,store,provider; - it imposes a specific data flow (unidirectional data flow);
- it dictates the application's architecture (modules, action types, etc.).
Example of typical Redux boilerplate:
dispatch({ type: 'INCREMENT' })In Zustand
Zustand is unopinionated: you decide for yourself how to store, change, and structure the state.
const useStore = create((set) => ({
count: 0,
increase: () => set((s) => ({ count: s.count + 1 })),
}))If you want, make several stores. If you want, put everything into one. If you want, split by modules or by features. Zustand does not interfere.
What "unopinionated" means in the context of Zustand
| Area | What "unopinionated" means |
|---|---|
| Architecture | No mandatory patterns (MVC, Flux, slices, etc.) |
| API | A minimal set of methods (set, get, subscribe) - and that's it |
| Store organization | You can store everything in one store or split it into several |
| Typing | You can use TypeScript, but you can also skip it |
| React integration | The store can also be used outside React |
| Middleware | Added as needed (persist, devtools, immer, etc.) |
Advantages of the unopinionated approach
- Flexibility - you define the architecture yourself.
- Simplicity - you can start with 5 lines of code.
- Compatibility - easily integrates with any approach (Flux, MVVM, Feature-Sliced Design, etc.).
- Easy refactoring - no need to rewrite the architecture when things change.
A possible downside
"Unopinionated" = "No rules" If the project is large and the team has no shared conventions, the structure of Zustand stores can become chaotic.
That's why real projects often introduce their own internal "opinionated" rules:
- one store per feature,
- name all actions by a template,
- keep state and types in separate files, and so on.
Summary
| Parameter | Redux | Zustand |
|---|---|---|
| Opinionated | Yes - strict architecture | No - flexibility and freedom |
| Boilerplate | A lot | Minimal |
| Data flow | Rigidly defined | Your choice |
| Support outside React | Difficult | Out of the box |
| Usage | "By the rules" | "However you want" |
Short Answer
Interview readyA concise answer to help you respond confidently on this topic during an interview.