Suggest an editImprove this articleRefine the answer for “The unopinionated principle”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)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. **Key point:** you decide for yourself how to store, change, and structure the state.Shown above the full answer for quick recall.Answer (EN)ImageWhen 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: ```javascript dispatch({ type: 'INCREMENT' }) ``` ### In Zustand Zustand is **unopinionated**: you decide for yourself how to store, change, and structure the state. ```javascript 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" |For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.