pmndrs · dai-shi · Jan 10, 2023 · Jan 7, 2023 · Jan 10, 2023
diff --git a/docs/getting-started/comparison.md b/docs/getting-started/comparison.md
@@ -20,7 +20,7 @@ immutable state model. However, Redux, requires your app to be wrapped in
 context providers; Zustand does not.
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number
@@ -39,7 +39,7 @@ const useCountStore = create<State & Actions>((set) => ({
 ```
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number
@@ -129,7 +129,7 @@ recommended that you manually apply render optimizations by using selectors.
 **Zustand**
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number
@@ -234,7 +234,7 @@ Zustand is based on the **immutable** state model, while Valtio is based on the
 **Zustand**
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   obj: { count: number }
@@ -264,7 +264,7 @@ that you manually apply render optimizations by using selectors.
 **Zustand**
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number
@@ -307,7 +307,7 @@ suitable when access outside of React is required.
 **Zustand**
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number
@@ -343,7 +343,7 @@ selectors.
 **Zustand**
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number
@@ -392,7 +392,7 @@ identities, additionally, Recoil needs to wrap your app in a context provider.
 **Zustand**
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number
@@ -429,7 +429,7 @@ manually apply render optimizations by using selectors.
 **Zustand**
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 type State = {
   count: number

diff --git a/docs/getting-started/introduction.mdx b/docs/getting-started/introduction.mdx
@@ -36,7 +36,7 @@ yarn add zustand
 Your store is a hook! You can put anything in it: primitives, objects, functions. The `set` function _merges_ state.
 
 ```jsx
-import create from 'zustand'
+import { create } from 'zustand'
 
 const useStore = create((set) => ({
   bears: 0,

diff --git a/docs/guides/connect-to-state-with-url-hash.md b/docs/guides/connect-to-state-with-url-hash.md
@@ -8,7 +8,7 @@ nav: 12
 If you want to connect state of a store to URL hash, you can create your own hash storage.
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { persist, StateStorage } from 'zustand/middleware'
 
 const hashStorage: StateStorage = {

diff --git a/docs/guides/how-to-reset-state.md b/docs/guides/how-to-reset-state.md
@@ -6,7 +6,7 @@ nav: 13
 The following pattern can be used to reset the state to its initial value.
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 // define types for state values and actions separately
 type State = {
@@ -47,7 +47,7 @@ const useSlice = create<State & Actions>()((set, get) => ({
 Resetting multiple stores at once
 
 ```ts
-import _create, { StateCreator } from 'zustand'
+import { create: _create, StateCreator } from 'zustand'
 
 const resetters: (() => void)[] = []
 

diff --git a/docs/guides/immutable-state-and-merging.md b/docs/guides/immutable-state-and-merging.md
@@ -8,7 +8,7 @@ Like with React's `useState`, we need to update state immutably.
 Here's a typical example:
 
 ```jsx
-import create from 'zustand'
+import { create } from 'zustand'
 
 const useCountStore = create((set) => ({
   count: 0,
@@ -36,7 +36,7 @@ The `set` function merges state at only one level.
 If you have a nested object, you need to merge them explicitly. You will use the spread operator pattern like so:
 
 ```jsx
-import create from 'zustand'
+import { create } from 'zustand'
 
 const useCountStore = create((set) => ({
   nested: { count: 0 },

diff --git a/docs/guides/maps-and-sets-usage.md b/docs/guides/maps-and-sets-usage.md
@@ -9,7 +9,7 @@ you do it by calling `setState` on it:
 **You can view a codesandbox here: https://codesandbox.io/s/late-https-bxz9qy**
 
 ```js
-import create from 'zustand'
+import { create } from 'zustand'
 
 const useFooBar = create(() => ({ foo: new Map(), bar: new Set() }))
 

diff --git a/docs/guides/slices-pattern.md b/docs/guides/slices-pattern.md
@@ -31,7 +31,7 @@ export const createBearSlice = (set) => ({
 You can now combine both the stores into **one bounded store**:
 
 ```js
-import create from 'zustand'
+import { create } from 'zustand'
 import { createBearSlice } from './bearSlice'
 import { createFishSlice } from './fishSlice'
 
@@ -81,7 +81,7 @@ export const createBearFishSlice = (set) => ({
 Combining all the stores together is the same as before.
 
 ```js
-import create from 'zustand'
+import { create } from 'zustand'
 import { createBearSlice } from './bearSlice'
 import { createFishSlice } from './fishSlice'
 import { createBearFishSlice } from './createBearFishSlice'
@@ -100,7 +100,7 @@ Adding middlewares to a combined store is the same as with other normal stores.
 Adding `persist` middleware to our `useBoundStore`:
 
 ```js
-import create from 'zustand'
+import { create } from 'zustand'
 import { createBearSlice } from './bearSlice'
 import { createFishSlice } from './fishSlice'
 import { persist } from 'zustand/middleware'

diff --git a/docs/guides/testing.mdx b/docs/guides/testing.mdx
@@ -11,7 +11,7 @@ When running tests, the stores are not automatically reset before each test run.
 Thus, there can be cases where the state of one test can affect another. To make sure all tests run with a pristine store state, you can mock `zustand` during testing and use the following code to create your store:
 
 ```jsx
-import actualCreate from 'zustand'
+import { create: actualCreate } from 'zustand'
 // const actualCreate = jest.requireActual('zustand') // if using jest
 import { act } from 'react-dom/test-utils'
 
@@ -43,7 +43,7 @@ In [jest](https://jestjs.io/), you can create a `__mocks__/zustand.js` and place
 If you are using zustand, as documented in [TypeScript Guide](./typescript.md), use the following code:
 
 ```tsx
-import actualCreate, { StateCreator } from 'zustand'
+import { create: actualCreate, StateCreator } from 'zustand'
 // const actualCreate = jest.requireActual('zustand') // if using jest
 import { act } from 'react-dom/test-utils'
 

diff --git a/docs/guides/typescript.md b/docs/guides/typescript.md
@@ -8,7 +8,7 @@ nav: 8
 The difference when using TypeScript is that instead of writing `create(...)`, you have to write `create<T>()(...)` (notice the extra parenthesis `()` too along with the type parameter) where `T` is the type of the state to annotate it. For example:
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 interface BearState {
   bears: number
@@ -71,7 +71,7 @@ So what we're saying is, the inference failure in case of `createFoo` is not rea
 Zustand lies that it implemented `create`'s type, it implemented only the most part of it. Here's a simple proof by showing unsoundness. Consider the following code:
 
 ```ts
-import create from 'zustand/vanilla'
+import { create } from 'zustand'
 
 const useBoundStore = create<{ foo: number }>()((_, get) => ({
   foo: get().foo,
@@ -136,7 +136,7 @@ This way, `T` gets inferred and you get to annotate `E`. Zustand has the same us
 Alternatively, you can also use `combine`, which infers the state so that you do not need to type it.
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { combine } from 'zustand/middleware'
 
 const useBearStore = create(
@@ -166,7 +166,7 @@ Note that we don't use the curried version when using `combine` because `combine
 You do not have to do anything special to use middlewares in TypeScript.
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { devtools, persist } from 'zustand/middleware'
 
 interface BearState {
@@ -187,7 +187,7 @@ const useBearStore = create<BearState>()(
 Just make sure you are using them immediately inside `create` so as to make the contextual inference work. Doing something even remotely fancy like the following `myMiddlewares` would require more advanced types.
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { devtools, persist } from 'zustand/middleware'
 
 const myMiddlewares = (f) => devtools(persist(f))
@@ -212,7 +212,7 @@ Also, we recommend using `devtools` middleware as last as possible. For example,
 Imagine you had to write this hypothetical middleware.
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 
 const foo = (f, bar) => (set, get, store) => {
   store.foo = bar
@@ -234,7 +234,7 @@ If you are eager to know what the answer is to this particular problem then you
 ### Middleware that doesn't change the store type
 
 ```ts
-import create, { State, StateCreator, StoreMutatorIdentifier } from 'zustand'
+import { create, State, StateCreator, StoreMutatorIdentifier } from 'zustand'
 
 type Logger = <
   T extends State,
@@ -279,7 +279,8 @@ const useBearStore = create<BearState>()(
 ### Middleware that changes the store type
 
 ```ts
-import create, {
+import {
+  create,
   State,
   StateCreator,
   StoreMutatorIdentifier,
@@ -334,7 +335,7 @@ console.log(useBearStore.foo.toUpperCase())
 The recommended way to use `create` is using the curried workaround like so: `create<T>()(...)`. This is because it enables you to infer the store type. But if for some reason you do not want to use the workaround, you can pass the type parameters like the following. Note that in some cases, this acts as an assertion instead of annotation, so we don't recommend it.
 
 ```ts
-import create from "zustand"
+import { create } from "zustand"
 
 interface BearState {
   bears: number
@@ -356,7 +357,7 @@ const useBearStore = create<
 ### Slices pattern
 
 ```ts
-import create, { StateCreator } from 'zustand'
+import { create, StateCreator } from 'zustand'
 
 interface BearSlice {
   bears: number

diff --git a/docs/integrations/immer-middleware.md b/docs/integrations/immer-middleware.md
@@ -22,7 +22,7 @@ npm install immer
 Updating simple states
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { immer } from 'zustand/middleware/immer'
 
 type State = {
@@ -52,7 +52,7 @@ export const useCountStore = create(
 Updating complex states
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { immer } from 'zustand/middleware/immer'
 
 interface Todo {

diff --git a/docs/integrations/persisting-store-data.md b/docs/integrations/persisting-store-data.md
@@ -18,7 +18,7 @@ for more details.
 ## Simple example
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { persist, createJSONStorage } from 'zustand/middleware'
 
 export const useBearStore = create(
@@ -483,7 +483,7 @@ const useHydration = () => {
 If the storage you want to use does not match the expected API, you can create your own storage:
 
 ```ts
-import create from 'zustand'
+import { create } from 'zustand'
 import { persist, StateStorage } from 'zustand/middleware'
 import { get, set, del } from 'idb-keyval' // can use anything: IndexedDB, Ionic Storage, etc.
 
@@ -549,7 +549,7 @@ Basic typescript usage doesn't require anything special
 except for writing `create<State>()(...)` instead of `create(...)`.
 
 ```tsx
-import create from 'zustand'
+import { create } from 'zustand'
 import { persist } from 'zustand/middleware'
 
 interface MyState {

diff --git a/docs/recipes/recipes.mdx b/docs/recipes/recipes.mdx
@@ -35,7 +35,7 @@ const treats = useStore(
 For instance, if you want to construct a single object with multiple state-picks inside, similar to redux's mapStateToProps, you can tell zustand that you want the object to be diffed shallowly by passing the `shallow` equality function.
 
 ```jsx
-import shallow from 'zustand/shallow'
+import { shallow } from 'zustand/shallow'
 
 // Object pick, re-renders the component when either state.nuts or state.honey change
 const { nuts, honey } = useStore(
@@ -131,7 +131,7 @@ subscribe(selector, callback, options?: { equalityFn, fireImmediately }): Unsubs
 ```
 
 ```jsx
-import create from 'zustand';
+import { create } from 'zustand';
 import { subscribeWithSelector, shallow } from 'zustand/middleware'
 const useStore = create(subscribeWithSelector(() => ({ paw: true, snout: true, fur: true })))
 
@@ -173,17 +173,17 @@ function Component() {
 Zustands core can be imported and used without the React dependency. The only difference is that the create function does not return a hook, but the api utilities.
 
 ```jsx
-import create from 'zustand/vanilla'
+import { createStore } from 'zustand/vanilla'
 
-const store = create(() => ({ ... }))
+const store = createStore(() => ({ ... }))
 const { getState, setState, subscribe, destroy } = store
 ```
 
 You can even consume an existing vanilla store with React:
 
 ```jsx
-import create from 'zustand'
-import vanillaStore from './vanillaStore'
+import { create } from 'zustand'
+import { vanillaStore } from './vanillaStore'
 
 const useStore = create(vanillaStore)
 ```
@@ -258,7 +258,7 @@ const useStore = create(
 <summary>How to pipe middlewares</summary>
 
 ```js
-import create from 'zustand'
+import { create } from 'zustand'
 import produce from 'immer'
 import pipe from 'ramda/es/pipe'
 
@@ -309,7 +309,7 @@ const immer =
 You can persist your store's data using any kind of storage.
 
 ```jsx
-import create from 'zustand'
+import { create } from 'zustand'
 import { persist } from 'zustand/middleware'
 
 export const useStore = create(