Ramda's pipe could be use to remove simplify middlewares

[Yhozen]

To be honest I fell in love the first time that I used ramda and I feel like the pipe method could add a lot of value to zustand, you can add as many middlewares as you wish as long as create is the last argument.

I would love to open some discussion about how this behavior could be added as a own feature. (It's an overkill to add ramda just to use pipe)

import create from "zustand"
import produce from "immer"
import pipe from "ramda/es/pipe"

const log = config => (set, get, api) =>
  config(
    args => {
      console.log("  applying", args)
      set(args)
      console.log("  new state", get())
    },
    get,
    api
  )

// Turn the set method into an immer proxy
const immer = config => (set, get, api) =>
  config(fn => set(produce(fn)), get, api)

const createStore = pipe(log, immer, create)

const useStore = createStore(set => ({
  bears: 1,
  increasePopulation: () => set(state => ({ bears: state.bears + 1 }))
}))

export default useStore

[dai-shi]

Thanks for opening up a discussion.

Some questions in my mind are:

• This pattern will not affect the core api. You can keep using ramda/pipe, correct?
• We could add pipe in middleware.ts, but what is wrong with using ramda/pipe? It shouldn't be too big. It should be battle tested.
• I'm not sure if there are other use cases than log+immer.
• It becomes hard to add TypeScript support, if we use pipe, no? cf. Typescript version for zustand redux middleware with dispatch  #212

[chrissantamaria]

@cmlarsen just ran into this, ended up creating my own pre-configured unary persist middleware and piping with that:

import produce, { Draft } from 'immer';
import { pipe } from 'ramda';
import create, { State, StateCreator } from 'zustand';
import { persist } from 'zustand/middleware';

// From https://github.com/pmndrs/zustand#middleware
const withImmer = <T extends State>(
  config: StateCreator<T, (fn: (draft: Draft<T>) => void) => void>
): StateCreator<T> => (set, get, api) =>
  config((fn) => set(produce<T>(fn)), get, api);

const withPersist = <T extends State>(config: StateCreator<T>) =>
  persist(config, { name: 'some-store' });

const createStore = pipe(withImmer, withPersist, create);

export default createStore;

[dai-shi]

That looks nice, actually.

[flycrum]

Hey team, I'm a big fan of zustand and have been working through several of the same TypeScript challenges mentioned above. I don't want to be too presumptive about your vision for this library and what may or may not be consistent with that, but I have worked out some potential solutions that I thought I'd share cause they're making my dev life a lot easier.

First stop, the ramda pipe solution works nicely! I'd assume it's a bit hardcore for some devs as the setup and additional typings are more than one might expect out of the box (they resemble more of the internals of a framework). So I wondered if I could figure something else out without adding another package for piping that might actually be even easier to work without having to expose the internals of zustand to add middleware options/args. To this end, I created a wrapper function called createWith that largely resembles the typings of create but with additional support for the redux middleware's object-based createState that uses function overloading to differentiate between each possible state type and then passes the return type of the 1st middleware to the 2nd middleware and that return type to the 3rd and so on. This was easy enough to pipe for the regular state types (the first overloaded function types) but got trickier with redux since its signature is so different than everything else and its state type changes during composition (hence a 2nd overloaded function type). Long story short, I've tested it out with the following combination of middlewares and here's how they look:

Persist was really clean:

export const useStore = createWith<StatePersist>(
	(set, get) => ({
		fishes: 0,
		addAFish: () => set({ fishes: get().fishes + 1 })
	}),
	state => persist(state, {
		name: "food-storage",
		getStorage: () => sessionStorage,
	}),
	devtools,
)

Redux has a few extra types above it, but I wasn't trying to entirely solve for that:

export const useStore = createWith(
	initialState,
	state => redux(reducer, state),
	devtools,
)
export const api = (useStore as any) as API<typeof initialState, Args>

Immer and logs could both use quite a bit of work to clean up and fix some specific implementation typings so I won't pollute this message with the specifics, but here's how piping would look:

export const useStore = createWith<StateImmer>(
	(set) => ({
		bees: false,
		setBees: (input: any) => set((state) => void (state.bees = input)), // todo - fix any typings
	}),
	immer,
	log,
	devtools
)

So all of the typings work great here, in the components consuming it, etc... and, even better, when hovering over the state arg (for something like state => redux(...) it will actually show the current type returned by the previous middleware in the list of params!

One final thought, one of the other cool things about how createWith currently works is that it's very lightweight (the logic is all of 1 line...the magic is in the function overloading typings) and all of its internals and typings could be worked back into the core's create function with 100% backward compatibility support so it wouldn't even require a new function to the API or anything.

I'm happy to put together a demo or create a pull request if you'd like to see it in action. Just wanted to share my findings and, should I be able to help in any way, contribute back to the project!

[marko-hologram]

@flycrum it would be great to see that code in action. I'm trying to get some of this working, but these existing comments are having issues and don't produce proper typing. Would love to get a working example since I'm struggling a bit with this😅

I'm actually trying to create a single function that would use immer and devtools automatically so that I don't have to use them manually when declaring each store, but I'm stuck with Typescript.

I got this far:

import { Draft, produce } from "immer";
import create, { State, StateCreator } from "zustand";
import { devtools } from "zustand/middleware";

// https://docs.pmnd.rs/zustand/recipes#middleware
const withImmer =
  <TState extends State>(config: StateCreator<TState, (fn: (draft: Draft<TState>) => void) => void>): StateCreator<TState> =>
  (set, get, api) =>
    config((fn) => set(produce<TState>(fn)), get, api);

export const createApplicationStore = <TState extends State>(createState: StateCreator<TState>) => create(devtools(withImmer(createState)));

Code actually works, but that withImmer part is giving me trouble regarding types and I didn't get to using persist middleware yet. I don't really care about using any pipe function, but if that will make some TS part of this easier that's ok, I can use pipe from ramda in that case.

[vaynevayne]

@cmlarsen just ran into this, ended up creating my own pre-configured unary persist middleware and piping with that:

import produce, { Draft } from 'immer';
import { pipe } from 'ramda';
import create, { State, StateCreator } from 'zustand';
import { persist } from 'zustand/middleware';

// From https://github.com/pmndrs/zustand#middleware
const withImmer = <T extends State>(
  config: StateCreator<T, (fn: (draft: Draft<T>) => void) => void>
): StateCreator<T> => (set, get, api) =>
  config((fn) => set(produce<T>(fn)), get, api);

const withPersist = <T extends State>(config: StateCreator<T>) =>
  persist(config, { name: 'some-store' });

const createStore = pipe(withImmer, withPersist, create);

export default createStore;

State 'State' is deprecate

[LeoRedin]

How should I add persist from zustand middleware using both log and immer from the same example? Is it possible or I should make it manual because of persist's configuration?

[chrissantamaria]

see my response above #224 (reply in thread)

[peterblockman]

@LeoRedin were you able to do it?

I tried this but it did not work

const log = <T extends State>(config: StateCreator<T>) => (
  set: SetState<T>,
  get: GetState<T>,
  api: StoreApi<T>,
) => config((args: any) => {
  console.log('  applying', args);
  set(args);
  console.log('  new state', get());
}, get, api);

const createStore = pipe(log, create);

error in this line const createStore = pipe(log, create);

No overload matches this call.
  The last overload gave the following error.
    Argument of type '<T extends object>(config: StateCreator<T>) => (set: SetState<T>, get: GetState<T>, api: StoreApi<T>) => T' is not assignable to parameter of type '(v1: unknown, v2: unknown, v3: unknown, v4: unknown, v5: unknown, v6: unknown) => StateCreator<object, SetState<object>, GetState<object>, any> | StoreApi<object>'.
      Types of parameters 'config' and 'v1' are incompatible.
        Type 'unknown' is not assignable to type 'StateCreator<object, SetState<object>, GetState<object>, StoreApi<object>>'.ts(2769)
pipe.d.ts(38, 18): The last overload is declared here.

[dennisbouwpas]

@chrissantamaria I tried your example

 const createStore = pipe(withImmer, withPersist, create);

But get ts error

Argument of type '<T extends object>(config: StateCreator<T>) => (set: SetState<T>, get: GetState<T>, api: StoreApi<T> & { persist: { setOptions: (options: Partial<PersistOptions<T, Partial<T>>>) => void; ... 4 more ...; onFinishHydration: (fn: PersistListener<...>) => () => void; }; }) => T' is not assignable to parameter of type '(a: StateCreator<T, SetState<T>, GetState<T>, StoreApi<T>>) => StateCreator<object, SetState<object>, GetState<object>, any> | StoreApi<...>'.
  Type '(set: SetState<T>, get: GetState<T>, api: StoreApi<T> & { persist: { setOptions: (options: Partial<PersistOptions<T, Partial<T>>>) => void; ... 4 more ...; onFinishHydration: (fn: PersistListener<...>) => () => void; }; }) => T' is not assignable to type 'StateCreator<object, SetState<object>, GetState<object>, any> | StoreApi<object>'.
    Types of parameters 'get' and 'get' are incompatible.
      Type 'object' is not assignable to type 'T'.
        'object' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'object'.ts(2345)
        
       const withPersist: <T extends object>(config: StateCreator<T, SetState<T>, GetState<T>, StoreApi<T>>) => (set: SetState<T>, get: GetState<...>, api: StoreApi<...> & {
    ...;
}) => T

oh and btw,

fn => set(produce<T>(fn))

causing

Error: [Immer] The first or second argument to `produce` must be a function