docs(issue-1215): restructure top level docs

docs/getting-started/comparison.md

@@ -0,0 +1,14 @@
+---
+title: Comparison
+description:
+nav: 2
+---
+
+⚠️ This doc is still under construction. https://github.com/pmndrs/zustand/discussions/1033
+
+## Why zustand over react-redux?
+
+- Simple and un-opinionated
+- Makes hooks the primary means of consuming state
+- Doesn't wrap your app in context providers
+- [Can inform components transiently (without causing render)](recipes#transient-updates-for-often-occurring-state-changes)

docs/getting-started/concepts.md

@@ -0,0 +1,7 @@
+---
+title: Concepts
+description:
+nav: 1
+---
+
+⚠️ This doc is still under construction. https://github.com/pmndrs/zustand/discussions/1033

docs/introduction.mdx → docs/getting-started/introduction.mdx

@@ -4,11 +4,12 @@ description: How to use Zustand
 nav: 0
 ---
 
-:warning: This doc is still under construction. https://github.com/pmndrs/zustand/discussions/1033
+⚠️ This doc is still under construction. https://github.com/pmndrs/zustand/discussions/1033
 
 <p align="center">
-  <img width="500" src="https://docs.pmnd.rs/zustand-resources/bear.png" />
+  <img width="600" src="https://github.com/pmndrs/zustand/raw/main/bear.jpg" />
 </p>
+
 A small, fast and scalable bearbones state-management solution. Has a comfy api based
 on hooks, isn't boilerplatey or opinionated, but still just enough to be explicit
 and flux-like.
@@ -21,7 +22,7 @@ You can try a live demo [here](https://codesandbox.io/s/dazzling-moon-itop4).
 npm install zustand
 ```
 
-### First create a store
+## First create a store
 
 Your store is a hook! You can put anything in it: primitives, objects, functions. The `set` function _merges_ state.
 
@@ -35,7 +36,7 @@ const useStore = create((set) => ({
 }))
 ```
 
-### Then bind your components, and that's it!
+## Then bind your components, and that's it!
 
 Use the hook anywhere, no providers needed. Select your state and the component will re-render on changes.
 
@@ -50,12 +51,3 @@ function Controls() {
   return <button onClick={increasePopulation}>one up</button>
 }
 ```
-
-#### Why zustand over react-redux?
-
-- Simple and un-opinionated
-- Makes hooks the primary means of consuming state
-- Doesn't wrap your app in context providers
-- [Can inform components transiently (without causing render)](recipes#transient-updates-for-often-occurring-state-changes)
-
----

docs/auto-generating-selectors.md → docs/guides/auto-generating-selectors.md

@@ -1,6 +1,6 @@
 ---
 title: Auto Generating Selectors
-nav: 12
+nav: 7
 ---
 
 It is recommended to use selectors when using either the properties or actions from the store.

docs/event-handler-in-pre-react-18.md → docs/guides/event-handler-in-pre-react-18.md

@@ -1,6 +1,6 @@
 ---
 title: Calling actions outside a React event handler in pre React 18
-nav: 10
+nav: 11
 ---
 
 Because React handles `setState` synchronously if it's called outside an event handler. Updating the state outside an event handler will force react to update the components synchronously, therefore adding the risk of encountering the zombie-child effect.

docs/flux-inspired-practice.md → docs/guides/flux-inspired-practice.md

@@ -1,6 +1,6 @@
 ---
 title: Flux inspired practice
-nav: 3
+nav: 6
 ---
 
 Although zustand is an unopinionated library, here's one of the recommended usages:

docs/immutable-state-and-merging.md → docs/guides/immutable-state-and-merging.md

@@ -1,6 +1,6 @@
 ---
 title: Immutable state and merging
-nav: 2
+nav: 5
 ---
 
 Like `useState`, we need to update state immutably.

docs/maps-and-sets-usage.md → docs/guides/maps-and-sets-usage.md

@@ -1,6 +1,6 @@
 ---
 title: Map and Set Usage
-nav: 13
+nav: 12
 ---
 
 You need to wrap Maps and Sets inside an object, and when you want it's update to be reflected (e.g. in React),

docs/practice-with-no-store-actions.md → docs/guides/practice-with-no-store-actions.md

@@ -1,6 +1,6 @@
 ---
 title: Practice with no store actions
-nav: 9
+nav: 8
 ---
 
 The recommended usage in the Readme is to colocate actions within the store.

docs/testing.mdx → docs/guides/testing.mdx

@@ -1,7 +1,7 @@
 ---
 title: Testing
 description: How to test your new store
-nav: 8
+nav: 10
 ---
 
 ## Resetting state between tests in **react-dom**

docs/typescript.md → docs/guides/typescript.md

@@ -1,6 +1,6 @@
 ---
 title: TypeScript Guide
-nav: 4
+nav: 9
 ---
 
 ## Basic usage

docs/updating-nested-state-object-values.md → docs/guides/updating-nested-state-object-values.md

@@ -1,6 +1,6 @@
 ---
 title: Updating nested state object values
-nav: 7
+nav: 4
 ---
 
 ## Deep nested object

docs/persisting-store-data.md → docs/integrations/persisting-store-data.md

@@ -1,6 +1,6 @@
 ---
 title: Persist middleware
-nav: 6
+nav: 15
 ---
 
 The persist middleware enables you to store your Zustand state in a storage (e.g. `localStorage`, `AsyncStorage`, `IndexedDB`, etc...) thus persisting it's data.

docs/v4-migration.md → docs/migrations/v4-migration.md

@@ -1,6 +1,6 @@
 ---
 title: v4 Migrations
-nav: 5
+nav: 17
 ---
 
 If you're not using the typed version (either via TypeScript or via JSDoc) then there are no breaking changes for you and hence no migration is needed either.

docs/zustand-v3-create-context.md → docs/previous-versions/zustand-v3-create-context.md

@@ -1,6 +1,6 @@
 ---
 title: createContext from zustand/context
-nav: 11
+nav: 16
 ---
 
 A special `createContext` is provided since v3.5,

docs/recipes.mdx → docs/recipes/recipes.mdx

@@ -1,10 +1,10 @@
 ---
 title: Recipes
 description: How to do all you need with Zustand
-nav: 1
+nav: 13
 ---
 
-:warning: This doc is still under construction. https://github.com/pmndrs/zustand/discussions/1033
+⚠️ This doc is still under construction. https://github.com/pmndrs/zustand/discussions/1033
 
 ## Fetching everything