Launching an Enterprise React & Redux App – Part 1
This is the first post in a 6 part series

This is the first post in a 6 part series walking you through the process of building an enterprise application in React and Redux.

We found TodoMVC (and other examples like that) to be far too lacking when it came down to building real, scalable applications. We needed examples of paging, how to organize our code so we weren’t bogged down 1 year in, and how the heck to add pagination to redux.

Oh yeah, and we’re pretty opinionated.

Part 1: Getting Setup

We consider this a work in progress and plan to extract a sample functioning project out of this once we’re all finished, complete with a full CRUD system organized for enterprise development.

We’ll walk you our design decisions, and please feel free to contribute. We consider this a living style guide and will be updated as we learn more about the best practices when it comes to large scale enterprise React/Redux development.


I’m not going to go into the Webpack VS Gulp VS Grunt debate, or how to configure webpack. We’ve started our project with a fantastic react/redux starter kit that handles most of the design decisions for us.

I did want to mention however one awesome configuration detail of this starter kit is using resolve.root! This has been a lifesaver for us and allowed us to reorganize our code a good amount without breaking trillions, yes TRILLIONS of relative require paths.

resolves: {
  root: [path.resolve(__dirname, ‘src’), path.resolve(__dirname, ‘node_modules’)],
  extensions: [”, ‘.js’, ‘.jsx’, ‘.coffee’]

This is a lifesaver when avoiding code like this:

import Bojangles from "../../../../shared/bojanges"
import Firewater from "../../../firewater"

Instead you can do:

import Bojangles from “components/shared/bojanges”
import Firewater from “components/firewater”


We’ll be using modular CSS which already comes baked in free with our starter kit. You can import your CSS stylesheet just like you would another component

import style from “./index.scss”

Then you can access your CSS properties like a javascript object. The css-modules configuration automatically adds the component name and a unique hash to prevent any conflict.

import style from "./index.scss"
import React, { Component, PropTypes } from "react"

export default class Tabs extends Component {
  render (){    
    return () 

Then you can access your CSS properties like a javascript object. The css-modules configuration automatically adds the component name and a unique hash to prevent any conflict.


  • Short descriptive property names .name instead of .history-item--name
  • No chance of conflict
  • Can put CSS in same folder as component to ensure everything is in one place


Organizing our Components

For this project, we’ll be following the principles of atomic design. What is Atomic design? – Atomic design is a methodology used to construct web design systems. –

Here’s an awesome post by Joey Di Nardo about applying atomic design to React.

Icons made by Yannick, Freepik from

One Folder Per Component

Yeah I know it sounds crazy, that’s a TON of folders. I was apprehensive myself until I tried it out and felt it really cleaned things up.


  • Allows us to add more info to each component without it appearing overwhelming (CSS, Images etc)
  • Allows us to put the test right in the folder, so we can quickly reference it without digging into a deeply nested “test” folder.
  • Allows each component to potentially be packaged as an NPM module, since it has all its assets in the same place.


What is Redux? It’s a Predictable state container for JavaScript apps. Redux has become the industry darling as far as Flux implementations go. I’d say it’s safe to say Redux has won in terms of support. Thank God, because my eyes were starting to bleed with all the competing flavors of flux.

Organizing your Redux Code

We’ve taken a cue from the NuclearJS guys (another solid framework) and decided to implement our domain logic in modules.

Then you can import the module where you need it.

import Entities from “modules/entities”

There’s a few other proposals for code structure around a redux app, another one from redux-form creator Erik Rasmussen being “ducks“. I personally found that when dealing with a large app with many domains, modules just made more sense.

Reducer Structure

We’ve decided to organize our reducers in terms of function, instead of domain. We started off making a reducer per domain. Something like “contacts reducer”, “companies reducer”, “tasks reducer” etc. We quickly found ourself replicating a lot of the base logic in each reducer (pagination, filtering, editing etc), and decided to instead reorganize our reducers to be named according to the function they perform.

More like

– entities
— pagination
— filters
— sorts

This allowed us to keep the reducers light, simple, focused and testable. Within each of our function focused reducers, we scope entities by domain, so something like:

— contacts
— companies
— contacts
— companies

We often have multiple reducers listening to the same actions like FETCH_ENTITIES_SUCCESS and once the data is received, spread the responsibility to the relevant reducers.


We’re going to commit to Immutable-js. I know it’s scary, it’s somewhat big and it turns pretty vanilla javascript objects into monsters, but it’s worth it.

We won’t have our entire reducer state immutable, but they will always be immutable at the second level. We choose immutable because it takes the guesswork out of keeping things immutable, and allows for fast shallow comparison in react components

Getting Your Hands Dirty

If you want to get started, we recommend this starter kit! It’s very well configured and has a solid set of dependencies.

Here’s a few more things we’ve installed on top.

> npm install react redux react-redux reselect immutable-js redux-thunk redux-promise-middleware redux-form superagent normalizr reselect classnames –save
> npm install chai-immutable json-server –save-dev

Part 1 Recap

— Use Modular CSS

— Organize your components with Atomic Design
— One folder per component

— Organize your code into domain specific modules
— Think of naming reducers in terms of their specific function, not the domain they serve

What’s Next?

The next post we’ll write about mocking up our application, what tool we used and how it’s helped our workflow.

— Part 1: Getting setup
— Part 2: Mocking up the project
— Part 3: Slicing it to React component-friendly HTML/CSS
— Part 4: Converting to Atomic Design React Components
— Part 5: Adding Redux (with a mocked API responses)
— Part 6: Adding the backend server

Hope you enjoyed it. Part 1: Mocking up the project coming soon!

I’ve been hacking at various business ideas since I was 16. I’m a full stack developer and love crafting user experiences. I’ve been nose deep in code since I put the legos down, and built several successful businesses in the process. I’ve lost some hair, gained some experience and throughly enjoyed the journey.