RFC: Redux Starter Kit

[timdorr]

Based on comments over in #2858 and earlier in #2295, it sounds like a preconfigured starter kit of Redux core + some common middleware + store enhancers + other tooling might be helpful to get started with the library.

I've started by reserving a package name (I'm not dead set on it, though) and we can start to fill in the blanks there. I would like to maintain the contents of that package here, so we don't have to set up another repo or anything. We may want to investigate a monorepo, but I don't think there's a pressing need currently.

One thing I'd like to investigate at the same time: splitting combineReducers to its own package. It's the one thing that gets prescriptive about how to structure and operate a store. It's obviously not the only way, but I worry many folks don't see past it.

As for what goes in a starter package, the short list in my mind includes one of the boilerplate reduction libraries (or something we build), popular middleware like thunks and sagas, and helpful dev tooling. We could have a subset package for React-specific users. In fact, I started a Twitter poll to find out if that's even necessary (please RT!).

I don't think we need to build a Create React App-like experience with a CLI tool and all that jazz. But something out of the box that gives a great dev experience with better debugging and less code.

[markerikson]

YES YES YES! I HAVE MANY OPINIONS AND WISHES FOR THIS! But I'll restrain myself and let the discussion get going some first.

One wishlist item I'd have that I'm not sure is feasible is built-in HMR for reducers automatically added in a createReduxStore() function. Unfortunately, my knowledge of Webpack and some experimentation says that's not very feasible, because you have to have hardcoded paths to reducer files in the Webpack module.hot.accept() callbacks. Not sure how Parcel or other bundlers handle that.

[markerikson]

So, initial request for feedback from everyone:

• What are the key requirements we would want to satisfy with this package?
• What existing packages would you suggest to help fulfill those requirements?
• How can we best combine those packages to keep things simple for the end user?

[theKashey]

Lets name 3 key points, where possible variants will be isolated from each other.

1. First point. Reducer managers
   1.0 Vanilla (it IS the case here?)
   1.1 Immer.js
   1.2 Coredux
   1.3 100500 more packages

2. Second point. Middlewares
   2.0 Vanilla (is it the case?)
   2.1 Sagas
   2.2 Epics
   2.3 100500 more packages.

3. Third point. React integration
   3.0. Vanilla (it IS the case here?)
   3.1. Subspace
   3.2 Restate
   3.3 100500 more packages.

4th, bonus, point
4.0 Testing all this stuff in a boilerplate.

It is impossible to pick "the chosen ones", for example I love and use both Sagas and Epics, but possible to provide some "cooking receipts" and recommendations for combinations.

For example most of redux users aware only about middlewares. A small part also doing something with reducers(ok lots heard about immutable.js), just a few ones enhance React integration.

Starter Kit could just help build for full and rich approach from the beginning. Or one need more that one Starter Kit.

[markerikson]

Asked for feedback on setup/boilerplate pain points on Twitter: https://twitter.com/acemarke/status/969040835508604929

[hswolff]

Copying my response on twitter:

I’ve explicitly stayed away from adding redux boilerplate as IMO it adds complexity when introducing ‘your way’ of doing redux to another person. I would love more prescriptive conventions enforced via code to make redux a more portable skill.

To that end, having a create-redux-app style repo - however designed more as a library than a framework - especially one explicitly endorsed by Redux maintainers of best and recommended practices, I think would go a long way to solidifying and adding clarity on proper Redux usage.

[hswolff]

We've been talking a bit about this on Reactiflux, wanted to copy over a consolidation of desires for inclusion in this thread, some of this overlaps with the points you already listed @timdorr (so it's an enthusiastic confirmation).

1. wrapper around createStore with better defaults, i.e. easier way to add middleware, redux dev tools
2. built in immutable helper (immer?)
3. createReducer built in (the standard "reducer lookup table" utility)
4. reselect built-in
5. action creator that adheres to FSA
6. async action support / side effect support (flux, saga, what?)

[cassiozen]

Why not officially backing something that already exists, like Henrik Joreteg's redux-bundler?

https://github.com/HenrikJoreteg/redux-bundler

It's concise, opinionated (in a good way), allows for reuse of redux-related functionality across applications and still gives a nice solution for async handling.

[markerikson]

It's a fascinating-looking project, and one that I really want to investigate further, but it's also out of scope for what I want to do with this task.

What I really want to accomplish here is:

• Setting up a Redux store with a couple lines of code and minimal configuration choices needed (the Redux equivalent of the "zero-config JS" tagline Webpack and Parcel have been using).
• Similar to CRA, config stuff is basically hidden, with good defaults out of the box
• Inclusion of carefully selected packages to improve dev experience and, yes, "reduce boilerplate". For example, Immer would be a great choice because it drastically simplifies writing immutable reducer logic and freezes your state in dev. (My only hesitation there is that the appearance of code that's "mutating" would be confusing.)

I want to keep this effort fairly tightly scoped. I've been chatting with @hswolff and @nickmccurdy over in Reactiflux the last couple hours, and while the discussion has been great, we've already run through a dozen overlapping use cases and ideas that could really over-complicate things.

I want to get something useful, valuable, and viable put together without too much bikeshedding, and then have other discussions off to the side (like an API for making Redux "bundles" or "modules", etc).

[hswolff]

To kick off some initial boilerplating of APIs here's a basic idea for 1-3 of my list I posted above:

// #1
export function createStore({
    // If an object is given it's passed to combineReducers
    // otherwise it's just used directly.
    reducer: Object<String, Function> | Function,
    // Middleware is built-in and accepts an array of middleware functions.
    middleware: Array<MiddlewareFunction>,
    // Built-in support for devtools.
    // Defaults to NODE_ENV !== production
    devTools: boolean,
    // Same as current createStore.
    preloadedState,
    // Same as current createStore.
    enhancer,
}) {};

// Re-exported for easy usage.
export function combineReducers() {}

// #2
// Re-export immer as the built-in immutability helper.
import immer from 'immer';
export const createNextState = immer;

// #3
// Export an already written version of createReducer .
// Same thing as https://redux.js.org/recipes/structuring-reducers/refactoring-reducers-example#reducing-boilerplate
export function createReducer() {}

[markerikson]

Yep, I dig that. I'd then expect that it would either always add thunk() at the front of the middleware list, or possibly only if you didn't supply any middlewares yourself. We might not even want to allow the user to specify enhancers here. We'd add applyMiddleware() automatically if there's any middleware, and use the composeWithDevtools function from redux-devtools-extension if devTools : true. For purposes of this "easy setup" thing, I think we may want to eliminate "enhancers" from the things the user can configure.