autodux: generating Redux reducers, action creators and selectors from one declaration

One declaration, four kinds of artefact

Autodux calls itself Redux on autopilot, and the README's first example shows what that means. You call autodux with a slice name and an initial state:

export const {
  actions: {
    setUser, setUserName, setAvatar
  },
  selectors: {
    getUser, getUserName, getAvatar
  }
} = autodux({
  slice: 'user',
  initial: {
    userName: 'Anonymous',
    avatar: 'anon.png'
  }
});

What comes back is a full set of action creators, selectors, reducers and action type constants, described as everything you need for fully functional Redux state management. The key structural decision is that the return value is destructured at the point of declaration and exported directly, so the slice lives in one file rather than in a directory of small ones. The README's justification for the library is worth reading because it is unusually honest about the trade. Redux is great that it is such a low-level tool, allowing flexibility and letting the community experiment with patterns, and it is terrible that it is such a low-level tool, because most reducers spend most of their logic switching over action types and most actual state updates could be replaced with generic tools like concat payload to an array, remove object from array by some prop, or increment a number.

The argument for generating the ceremony

The Why section lists the four kinds of boilerplate Redux makes you write: action type constants, action creators, reducers and selectors. Then it makes the sharper point that most of the work is mechanical. Action types can be automatically generated by combining the name of the state slice with the name of the action, for example counter/increment, so the type string is never hand-typed and never has a typo. Lots of selectors just need to grab the state slice, which is a one-line function. Lots of action creators do not need arguments or payloads, just action types. And a beginner separating all of these into separate files has to open and import a whole bunch of files to get some simple state management into an app. The last item in that list is the real one for many teams, since the file count is what makes Redux feel heavy. The library's answer is that when you add this simple logic on top of Redux, you can do a lot more with a lot less code.

The default action and the default selector

The Automate Almost Everything with Defaults section is where the library earns its keep, and the two rules are easy to state. On the action side, a set${slice} action lets you set any key in your reducer, which is basically {...state, ...payload}, so with a slice called user the set creator is called setUser, and actions for set{key} exist for each key in your initial state, so a key called userName gives you an action called setUserName created automatically. On the selector side, selectors are automatically created for each key in your initial state, with get{key} existing for each key and get{slice} existing for the entire reducer state. For simple reducers, all the action creators, reducers and selectors can be created for you automatically, and all you have to do is specify the initial state shape and export the bindings. That is a narrower promise than a code generator over arbitrary Redux code, and it is the right one, because the generated names are predictable and a reader can infer the whole API from the initial state.

Where you hand the logic back to the library

The counter example shows the other mode, where the reducer function is written by hand and the library supplies everything around it:

import autodux, { id } from 'autodux';

export const {
  reducer,
  initial,
  slice,
  actions: {
    increment,
    decrement,
    multiply
  },
  selectors: {
    getValue
  }
} = autodux({
  // the slice of state your reducer controls
  slice: 'counter',

  // The initial value of your reducer state
  initial: 0,

  // No need to implement switching logic -- it's
  // done for you.
  actions: {
    increment: state => state + 1,
    decrement: state => state - 1,
    multiply: (state, payload) => state * payload
  },

  // No need to select the state slice -- it's done for you.
  selectors: {
    getValue: id
  }
});

Note the id import, which is the selector that returns the whole slice, and note that the action creators carry their type as a property so the reducer can switch on it without the type being written by hand. The result object is described in the README with the shape it returns, listing initial, actions, selectors, reducer and slice, with each action shown as a function carrying its type string. The point of the example is that nothing here is magic at the reducer level, the arithmetic is your code, and the library only removes the parts that never vary.

Action creators you can leave out entirely

The API Differences section makes the strongest case for the defaults, and it is a case about typing less. With plain Redux, setting a user name means writing an action creator that returns an object with a type and a payload. With autodux, if your action creator maps directly from input to payload, you can omit it, because the library will do it for you, and since that is the default behaviour you can omit the identity function entirely. The README's own example makes the reduction concrete, going from a full create and reducer pair to a single line of multiply: (state, payload) => state * payload. The rule for when you do need an action creator is spelled out too. You do not need to create action creators unless you need to map the inputs to a different payload output, and the example given is a translation between an auth provider user and your own application user objects, written as a destructuring function that maps userId to uid and displayName to userName. So the library's default covers the case where the payload is the input, and steps aside for the case where it is not.

What the object gives you at runtime

The README shows how the generated pieces are used, and the sequence is a plain Redux reduce with the generated reducer:

const actions = [
  increment(),
  increment(),
  increment(),
  decrement()
];

const state = actions.reduce(reducer, initial);

console.log(getValue({ counter: state })); // 2
console.log(increment.type); // 'counter/increment'

Two details are worth noticing. The selector takes the whole root state object, so getValue is called with { counter: state }, which is how a slice selector behaves. And the action creator carries its type as a property, so increment.type gives the string counter/increment, which is the value a reducer switches on and the value a test would assert. The package manifest shows the project is set up like a real library rather than a sketch, with eslint and eslint-config-prettier, prettier itself, husky and lint-staged for commit hooks, nyc for coverage with a coveralls reporter, riteway and tap-nirvana as the test runner, markdownlint and textlint for the documentation, and renovate for dependency updates. The test script runs the src test files through riteway, and there is a separate coverage script pair for local and CI use.

Where the defaults stop fitting, and what to check before adopting

The limits are inherent to a generator that assumes a flat slice. The default set action merges the payload into the state, which is the wrong shape for anything nested, and the default selectors read a key off the initial state, which means a state slice that is a list rather than a map gets no per-item selectors at all. A slice whose state is computed from other slices, or a reducer that needs to see several action types to produce one result, has to be written by hand, and at that point the library is only saving you the type string. The second limit is about the framework's age rather than its design. The release list tops out at v4.0.0 from 2018-07-30 with a note about fixing nested action objects, and v2.0.0 from 2018-03-16 for the Defaults API, while the package manifest in the repository reads version 5.0.3, which means the published version and the tagged releases are not the same line and the newest tag does not describe the current code. The last push to the repository was on 2026-10-20, so the file is still being touched.

Editorial conclusion

autodux suits a project that has accepted Redux as its state model and finds itself writing the same four files for every slice, because the library removes the part of Redux that is pure ceremony while leaving the reducer itself in your hands. It is the wrong tool if your team has already standardised on a different state approach, since it exists specifically to make Redux less verbose rather than to make state management simpler, and it is the wrong tool for deeply nested or derived state, where the generated defaults stop fitting. Verify first which version you are installing, because the manifest reads 5.0.3 while the newest tagged release visible in the release list is v4.0.0 from 2018-07-30.

Frequently asked questions

Official sources

1. ericelliott/autodux on GitHub
2. Issues
3. License: MIT
4. README
5. Releases