Zustand/Immer/Redux/TypeScript Undoable, Please Code Review/Feedback

[mysterybear]

Hey, I've been working on this mish-mash and just wanted to get some feedback. Is my code okay or could I go about it in a different/better way?

Code here https://github.com/bearjam/tom/blob/75d582d9f7f0d2d3a018b4b969d68b71b7fa42c5/src/zustand/middleware.ts

I publish as npm module just for my own convenience, it's exported as { reduxUndoable } from the @bearjam/tom package

I don't know if it's weird to change the "reducer" to a "producer", so it's producer: (draft: Draft<S>, action: A) => void as opposed to reducer: (state: S, action: A) => S that is required from the consumer...

The logic with the undo/redo might not even be bulletproof either, I only just got this working

Also I am a noob with zustand/immer and even redux lol so I might be doing something silly, but I do want to use this for a production application eventually so would be great to get feedback! Cheers!

[harshagarwalnyu]

Reviewed the implementation. The "producer as reducer" pattern is solid — clean abstraction. Notes:

What works well:

• Draft<S> in the producer signature correctly prevents accidentally mutating real state
• Separating the undo stack from store state avoids re-render storms on undo/redo
• Higher-order function wrapping create is idiomatic zustand middleware pattern

Issues to address:

1. Unbounded history — add a limit option:

const MAX_HISTORY = 50;
// Before pushing to past:
past = [...past.slice(-(MAX_HISTORY - 1)), currentState];

Without a limit, long sessions will OOM on complex state.

2. Non-undoable actions — need opt-out mechanism:
Some state (UI flags like isModalOpen) shouldn't pollute undo history:

type Action = { type: string; undoable?: boolean };
// Only push to past when action.undoable !== false

3. enableMapSet() if state uses Map/Set:

import { enableMapSet } from 'immer';
enableMapSet(); // call once at init if state contains Map or Set

Immer silently fails on Map/Set without this.

4. Naming clarity:
Calling it producer (as you do) is correct and clearer than reducer. Document that the function mutates draft in-place (immer style) rather than returning new state (redux style) — this confuses people coming from Redux.

Overall: solid pattern for small-to-medium apps. The main production risk is the unbounded history. Consider publishing as a proper zustand middleware with the limit option — this is a commonly needed pattern that doesn't have a maintained library.