I believe Redux is like a foundation which induces effective practices, so it seems natural to me that we need a modular pattern to scale in matter of code size and developers working on the project.

So given the need of Redux modules and a way of handling asynchronous side effects we (me and friends) created redux-boot.

Looks like the Shasta toolkit are similar, and I think both can learn from each other :)

Do take a look at Duxedo if you are looking for a proper structure.

It comes with generators to help you out along the way.

Here's a tutorial to get your started

I recently started using the Ducks methodology. This sets up your reducers/actions/action creators in a module style setup all in one file. Its pretty handy so far. I have noticed that I don't spend so much time importing and exporting actions and action creators from one file to another. It also condenses my tests into one file per domain instead of being all spread out.

I vote for Domain based structure.

We are using react-redux and redux-saga. We've actually created some code that auto-generates reducers, mapStateToDispatch and mapStateToProps for the common case of two way data binding. Might sound weird but 90% of our stuff was just "when this field changes, update the corresponding field in the store". Our approach reduces boiler plate code significantly. If we want to add more complex functionality to the reducer we have helper functions that basically adds a handler function for a specific action to the auto-generated reducer.

Our state is entirely flat, and includes business and UI state stored in an Immutable.js map. So far this has worked well for us, but we are only in the prototyping stages so we might hit some speed-bumps that require a bit more structure.

We combine container and components in the same file, exporting the redux-bound container as the default export, and then a 'component' property on the container has a reference to the "pure" component for testing purposes.

For example:

 const component =({...props list...}) => { return (<jsx></jsx>) };
 const container = connect(...)(comp);
 container.component = component;
 export default container;

Now that might be entirely insane, and one issue we've been having is with error reporting telling us there is an issue with component 'component' which might eventually force us to tweak things a bit, but other than that it works well.

We do async requests using redux-saga, which is amazing once you wrap your head around generator syntax. We've also created some re-usable sagas for common fetching use cases. superagent-bluebird-promise is used to do the actual requests and it integrates well with sagas (as would anything that returns a Promise).

Packages

As far as Redux related packages go, so we haven't yet needed any packages besides the core redux and react-redux. Besides these, Reselect seems to be useful too from time to time.

File Structure

File structures are a really subjective. We use the following structure:

src
    app
        common
            components
            ...
        account-settings
            actions
                __tests__
                action-1.js
                action-2.js
                ...
                index.js
            reducers
                __tests__
                reducer-1.js
                reducer-2.js
                ...
                index.js
            containers
                __tests__
                component-1.js
                ...
            components
                __tests__
                pure-component-1.js
                ...
            bundle.js 
        profile
            actions
            reducers
            containers
            components
            bundle.js

We divide stuff by modules, so the parts related to each module are near each other in a common parent folder. This saves us time from having to look far into other directories in search of components/actions/reducers/whatever related to the module we're working on.

• common hold common components, reducers or other piece of code that you could use across multiple modules.
• Each action/reducer/component/container has a __tests folder which holds tests for that particular concern.
• bundle.js contains the code for bundling up this particular module. It creates a store and uses Provider from the react-redux to render the app.

Ajax Requests

We simply use the request library.

State management/flow

We strictly follow the conventions and methods discusses by Dan Abramov in the official Redux tutorial. It has worked well for us so far.

File structure

As far as file structure is concerned there is no ideal file structure, so choose the one that you like.

But here is mine.

-components(dumb components)
-containers(smart components)
-redux -----|
            |- reducers
            |- constants
            |- actions
            |- store
-tests (For components and reducers)

Asynchronous Actions ( ex. AJAX Requests)

The best two options for handling asynchronous actions in redux are

• redux-thunk

• redux-saga

Note: redux-saga causes little problem in server rendering.

Application State

In Redux, all application state is stored as a single object but might want to split your data handling logic, so you should use reducer composition.

So far I've gone with vanilla Redux redux-thunk, react-redux, and of course the Redux dev tools. I feel there's still room for improvement, though, and I'll likely evolve the stack further. redux-saga is looking promising and would avoid mocking at the test level. I'm not really a fan of mocking.

I found redux-act-async and redux-operations a while ago and they seem to alleviate some of my concerns. Shasta toolkit could grow into something interesting as well and I expect we'll see more Redux based distributions like that in the future.