Confusing API for creating a Redux store

[sporto]

Here are some example on how to create a redux store. From the readme:

let store = createStore(counter);

From http://rackt.github.io/redux/docs/advanced/Middleware.html

let createStoreWithMiddleware = applyMiddleware(logger, crashReporter)(createStore);
let todoApp = combineReducers(reducers);
let store = createStoreWithMiddleware(todoApp);

From https://github.com/gaearon/redux-devtools

const finalCreateStore = compose(
  // Enables your middleware:
  applyMiddleware(thunk),
  // Provides support for DevTools:
  devTools(),
  // Lets you write ?debug_session=<name> in address bar to persist debug sessions
  persistState(window.location.href.match(/[?&]debug_session=([^&]+)\b/)),
  createStore
);

So sometimes you use createStore, sometimes createStoreWithMiddleware, sometimes compose.
I have to say that this is quite confusing. I understand that there is a lot of flexibility here but it will be nicer if there could be only one canonical way to build the final store, e.g. I I don't need any middleware then I just pass an empty array.

Please consider this

[nodu]

+1

[timdorr]

This is basic functional composition. createStore is the only way to create a store. Store enchancers, such as middleware, are concepts layered on top that are entirely optional.

[gaearon]

We should first fix #632 as suggested in #632 (comment), then it'll be normal compose() like in Lodash and easier to explain.

If you have a specific API to propose, please do.

[timdorr]

Maybe a crash course on functional programming might be helpful?

Usage is probably a lot more clear if you're familiar with functional concepts. There is no configuration with redux (e.g., no Express app.use() equivalent for middleware), just composition. That's very different if you're coming from other Flux-y implementations.

[timdorr]

Actually, how about elevating store enhancers to their own section in the docs, right before middleware? That way you introduce the concept of them, followed by an implementation. They are a fairly important concept to grok.

[gaearon]

We'll do that eventually. I want to make some API changes first, like #632 and #350.

[kevinold]

@timdorr

Maybe a crash course on functional programming might be helpful?

Absolutely! Anything that can be linked to in the Redux documentation to bring people up to speed on the functional concepts should be.

I've found the following resources very helpful so far:

http://www.pluralsight.com/courses/hardcore-functional-programming-javascript
http://functionaljavascript.com/

[kevinold]

Also this: https://github.com/DrBoolean/mostly-adequate-guide

[sporto]

I totally agree that a crash course on functional programming would be very nice and helpful.

Aside from that I wonder if it would be feasible to have a "simpler" way to create a store, configuration object style:

import { create } from 'redux'

const = create({
        middlewares: [
                thunkMiddleware,
                loggerMiddleware
        ],
        reducers: {
             users:  usersReducer,
             orders: ordersReducer,
        }
    })

Not sure how devTool() could fit here. But the idea would be to describe what you need in a declarative way and have this function compose things correctly.

Otherwise it would be nice if the docs and examples try to stick with one style of doing things e.g. using compose

[timdorr]

@sporto That is a pure functional programming anti-pattern. You don't use configuration to construct your store, you use composition. In that way, you aren't limited to solely the mechanisms thought out ahead of time. As you said, where does devTool() fit in?

By using higher order functions and functional composition (which is still declarative, by the way), redux doesn't have to concern itself with things like that. redux-devtools can hook in simply by adding itself to the chain of execution when the store is constructed.

[gaearon]

I'm compelled to close this, as there have been no specific API proposal that would work with middleware, devtools, etc.

[gaearon]

This is now addressed by #1294. Please let me know whether it solves the problem.