Skip to content

Cron-J/CSV-Redux

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

React Redux Starter Kit

Build Status dependencies

Starter kit to get you up and running with a bunch of awesome new technologies. This boilerplate provides server-side rendering of your routes (by way of Koa and react-router), and the sample application gives you a quick demo of Redux. All of this sits on top of a configurable, feature-rich Webpack build system that's already setup to provide unit testing, linting, hot reloading, sass imports with CSS extraction, and a whole lot more. Check out the full feature list below!

Redux, React-Router, and React are constantly releasing new API changes. If you'd like to help keep this boilerplate up to date, please contribute or create a new issue if you think this starter kit is missing something!

Want to use this starter kit without the server? There's a branch for that, check it out here!

Table of Contents

  1. Requirements
  2. Features
  3. Usage
  4. Webpack
  5. Styles
  6. Testing
  7. Utilities
  8. Server
  9. Deployment
  10. Troubleshooting

Requirements

Node (^4.0.0 | ^0.12.0) or io.js ^2.0.0.

Features

  • React (0.14.0-rc1)
    • Includes react-addons-test-utils (0.14.0-rc1)
  • react-router (1.0.0-rc1)
  • Redux (^3.0.0)
    • react-redux
    • redux-devtools
      • use npm run dev:nw to display in a separate window.
  • Koa
  • Immutable.js
  • Karma
    • Mocha w/ Chai and Sinon-Chai
    • PhantomJS
  • Babel
    • react-transform-webpack-hmr for hot reloading
    • react-transform-catch-errors for more visible error reporting
    • Uses babel runtime rather than inline transformations
  • Webpack
    • Separate server and client bundles
      • Client bundle splits app code from vendor dependencies
    • webpack-dev-server
    • sass-loader with CSS extraction
    • eslint-loader
    • Pre-configured folder aliases and globals

Usage

npm run dev also npm start

Runs the webpack build system just like in compile but enables HMR. The webpack dev server can be found at localhost:3000.

npm run dev:nw

Same as npm run dev but opens the debug tools in a new window.

npm run dev:no-debug

Same as npm run dev but disables devtools.

npm run compile

Runs the Webpack build system with your current NODE_ENV and compiles the application to disk (~/dist). Production builds will fail on eslint errors (but not on warnings).

npm run test

Runs all tests for the application. When run in a production build, failing tests will fail your build.

npm run test:unit

Similar to npm run test, but only runs unit tests. In development mode this will run in watch mode and re-run individual test files when they change.

npm run test:server

Runs the small test suite in ~/server/scripts/test.js. This will ideally be expanded in the future to instead act as an entry point similar to what exists for client-side tests.

npm run server:start

Kicks off the Koa server (defaults to localhost:4000).

npm run server:dev

Kicks off the Koa server with Nodemon so any file changes in ~/server will trigger a server restart.

npm run deploy

Helper script to run tests and then, on success, compile your application. Server tests that rely on the compiled server bundle will be run after compilation finishes.

Configuration

Basic project configuration can be found in ~/config/index.js. Here you'll be able to redefine your src and dist directories, as well as tweak what ports Webpack and WebpackDevServer run on.

Webpack

Configuration

There are two configuration files for the webpack compiler, client and server, located in ~/build/webpack and named accordingly. When the webpack dev server runs, only the client compiler will be used. When webpack itself is run to compile to disk, both the client and server configurations will be used. Settings that are bundle agnostic should be defined in ~/config/index.js and imported where needed.

Vendor Bundle

You can redefine which packages to treat as vendor dependencies by editing vendor_dependencies in ~/config/index.js. These default to:

[
  'history',
  'immutable',
  'react',
  'react-redux',
  'react-router',
  'redux',
  'redux-devtools',
  'redux-devtools/lib/react'
]

Aliases

As mentioned in features, the default Webpack configuration provides some globals and aliases to make your life easier. These can be used as such:

import MyComponent from '../../components/my-component'; // without alias
import MyComponent from 'components/my-component'; // with alias

  // Available aliases:
  actions     => '~/src/actions'
  components  => '~/src/components'
  constants   => '~/src/constants'
  containers  => '~/src/containers'
  dispatchers => '~/src/dispatchers'
  layouts     => '~/src/layouts'
  models      => '~/src/models'
  reducers    => '~/src/reducers'
  routes      => '~/src/routes'
  services    => '~/src/services'
  stores      => '~/src/stores'
  styles      => '~/src/styles'
  utils       => '~/src/utils'
  views       => '~/src/views'

Globals

__DEV__

True when process.env.NODE_ENV is development

__PROD__

True when process.env.NODE_ENV is production

__DEBUG__

True when the compiler is run with --debug (any environment).

__CLIENT__

True when the client bundler is running.

__SERVER__

True when the server bundler is running.

Styles

All .scss imports will be run through the sass-loader, extracted during production builds, and ignored during server builds. If you're requiring styles from a base styles directory (useful for generic, app-wide styles) in your JS, you can make use of the styles alias, e.g.:

// ~/src/components/some/nested/component/index.jsx
import `styles/core.scss`;

Furthermore, this styles directory is aliased for sass imports, which further eliminates manual directory traversing. An example nested .scss file:

// current path: ~/src/styles/some/nested/style.scss
// what used to be this:
@import '../../base';

// can now be this:
@import 'base';

Testing

To add a unit test, simply create .spec.js file anywhere in ~/src. The entry point for Karma uses webpack's custom require to load all these files, and both Mocha and Chai will be available to you within your test without the need to import them.

Utilities

This boilerplate comes with two simple utilities (thanks to StevenLangbroek) to help speed up your Redux development process. In ~/client/utils you'll find exports for createConstants and createReducer. The former is pretty much an even lazier keyMirror, so if you really hate typing out those constants you may want to give it a shot. Check it out:

import { createConstants } from 'utils';

export default createConstants(
  'TODO_CREATE',
  'TODO_DESTROY',
  'TODO_TOGGLE_COMPLETE'
);

The other utility, create-reducer, is designed to expedite creating reducers when they're defined via an object map rather than switch statements. As an example, what once looked like this:

import { TODO_CREATE } from 'constants/todo';

const initialState = [];
const handlers = {
  [TODO_CREATE] : (state, payload) => { ... }
};

export default function todo (state = initialState, action) {
  const handler = handlers[action.type];

  return handler ? handler(state, action.payload) : state;
}

Can now look like this:

import { TODO_CREATE } from 'constants/todo';
import { createReducer } from 'utils';

const initialState = [];

export default createReducer(initialState, {
  [TODO_CREATE] : (state, payload) => { ... }
});

Server

The application used by the server is pre-compiled, meaning the server does not load the application from source during runtime. While loading it at runtime sounds great, and a lot of examples do it, they neglect any incorporation of critical assets that aren't just JavaScript. As such, in order to support non-JS assets (read: sass), the application used by the server must be pre-bundled. The alternative would be preprocessing the server with webpack, and since any development on the server is likely to not touch rendering, it makes more sense to support a more dynamic server environment.

Deployment

Dokku Requirements

  • Add io.js as a buildpack:
    • In ~/ENV append: export BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs

Troubleshooting

Nothing yet. Having an issue? Report it and I'll get to it as soon as possible!

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published