opencredo/opencredo-react-boilerplate

opencredo-react-boilerplate

React and Redux boilerplate codebase.

Features

• react
• redux
• react-router
• react-router-redux – synchronises react router state with your redux store
• webpack
  • Configured with webpack-dev-middleware and webpack-hot-middleware
  • Hot Module Replacement with react-transform-hmr and babel-preset-react-hmre
  • SASS / SCSS
  • CSS modules
  • .eslintrc pre-loader
  • Support for production and development builds based on NODE_ENV
• react-addons-test-utils for unit testing
• Flowtype Static type checker (see FLOWTYPE.md for more info)
• Babel for ES2015 and beyond
  • Presets: es2015, react, stage-0, and react-hmre (development)
• react-bootstrap and react-router-bootstrap
• react-intl for i18n support with several example translations; using v2 beta: keep an eye on the RFC
• redux-form and redux-form-validation for form integration and validation
• Example production build script (npm run build)
• Basic support for restricted pages. Check src/routes.js for examples of restricted routes

Usage

First time

Clone this repo, then run npm install.

Windows users need to follow the instructions in FLOWTYPE.md to install the flow binaries.

Development

When you're developing, start webpack as follows:

npm run start       # standard development
npm run start:bs    # as above, but with browser-sync

Then open a browser at http://localhost:3000/.

Some useful commands:

npm run lint        # execute the eslint process on the codebase
npm run karma       # execute just the unit tests
npm run flow-check  # alias for `flow check`
npm run test        # execute flow checks, eslint and unit tests
npm run build       # run this just before you commit - the Travis-CI job runs this command

Most editors will report lint and type errors if properly configured. If you need help setting up your editor, we've put together a few tips for some of the more popular ones in the Editors document. If your editor is not listed and you'd like to contribute some tips, feel free to make a PR :-)

Production

To test a production build:

npm run build && (cd dist && python -m SimpleHTTPServer)

Then open a browser at http://localhost:8000/.

Directory Structure

.
├── config                      # Config: mostly used by build & webpack
│   ├── environments/           # Config overrides for different NODE_ENVs
│   └── index.js                # Config entry point. Modify to suit your needs
├── dist/                       # Built artifacts get put here (e.g. webpack.output)
├── server/                     # Express server files go here
│   ├── index.js                # Launches the express() server with webpack-hmr
├── src                         # The source code of the application
│   ├── api/                    # Modules that make API service calls
│   ├── components/             # React [functional|dumb|stateless] components
│   ├── containers/             # React "container" components (connected to store)
│   ├── declarations/           # Flowtype declarations would go here, if necessary
│   ├── pages/                  # Pages: React Components that live in routes
│   ├── redux/                  # Here we configure our redux stores, actions, reducers...
│   │   ├── modules/            # Redux modules would be collections of reducers + actions
│   │   ├── configure-store.js  # Redux store configured here (middleware, initial state, reducers...)
│   │   └── root-reducer.js     # Here we combine all our reducers
│   ├── shared/                 # Shared resources
│   ├── static/                 # Static assets. Some call this `public/`
│   ├── styles/                 # Global CSS styles (class names left intact)
│   ├── translations/           # Our i18n translations go here
│   ├── app.js                  # Application entry point
│   ├── app-config.js           # Global application settings
│   ├── index.html              # index.html template
│   └── routes.js               # All our routes
├── karma.conf.js               # (self explanatory)
├── package.json                # (self explanatory)
├── tests.karma.js              # (self explanatory)
└── webpack.config.js           # (self explanatory)

Note: see Dan Abramov's explanation about "Smart and Dumb Components".

Contributing

Please see CONTRIBUTING.md for how to get involved.

Changelog

Changelog

Credits

Much of the original codebase was taken from Dave Zuko's excellent react-redux-starter-kit. Thanks Dave!

opencredo-react-boilerplate's Issues

Add description of npm modules to README

There are a lot of modules used in this boilerplate code.

To help a developer understand why various modules have been chosen, it would be useful to have a list of them, and a brief description of why each is used.

This should be simple enough to implement as a bulleted list in the README; may end up as a separate .md file.

Unable to browse site

After following all the instructions and browsing to localhost:3000 i get this:

Cannot GET /

I also get errors in webpack:

ERROR in ./src/styles/app.scss
Module parse failed: C:\Users\*****\Downloads\opencredo-react-boilerplate-master\opencredo-react-boilerplate-master\src\styles\app.scss Unexpected character '@' (1:0)
You may need an appropriate loader to handle this file type.

Preliminary inquiry...

Hello Gentlemen,
I've got a proposition that I'd like you and your colleagues to consider as I'd like you all on board of a new open software initiative:
Under Araphel.org, an esoteric conclave would be established to oversight an OSI project called R3Stack (R3Stack.com is the stacks url)

Our main component is currently being finalized by Matt Krick with his Meatier development.
Basically it's a meteor-like stack build within react-redux-rethinkDB specifications, you can check it out here: https://github.com/mattkrick/meatier

Your beautiful creation would be the frontend (replacing the current meatier mui) as I have not see anything better or eloquent if I may say so, that I'd love kids to learn on, but we'll get to that in a moment.

Finally we are in preliminary talks with Alex Pustovalov of the Structor project which we hope to include too as an visual aspect to an concise functional programming is an great aid in teaching children while itself not obstructing or weighing in too much in unnecessary code; you can see here: https://github.com/ipselon/structor

The whole thing will either be entirely docker based as to simplify the installation/operation/deployment or we could utilize AZK as binding agent/control agent (tho since itself is also docker base it could be entirely unnecessary, however all this is open to discussion)

The reason for this stack, is to create a framework which unlike other frameworks, do not lend itself to be ridged and unchanging but rather continually evolve with community while providing kids with the best practice, that are always current and reflective of the react community; an full-spectrum solution with emphasis on functional programming that ever-improving.

Our aim would be to providing the best structure for learning by allowing kids to look at the current development practices, while at the same time having entire build for reverse engineering purposes as it is my belief that by such example the widest segment of differentiating potential that kids have could be sparked and nurtured.

By setting an ever evolving standard we can bring balance to the fractured and disjoined react [force ;) ] community and at the same time support the good practices while discarding unwanted ones.

The structure of Araphel.org in a way like that of a philosophical branch of the anonymous movement and itself will be in form of a round table, where each member does his best to express and contribute in whatever capacity they can while at the same time setting an example and nurturing community in general. We will essentially create by hackers for hacker - build-break-learn stack.

What would you say to that?

Document IDE setup

Start with Intellij/Webstorm, and leave space for others (sublime, Atom).

Abstract build process to single file

• add a file in the bin directory that runs everything for the build (abstracting the build process into a single point)
• update .travis.yml to use this instead of running the current npm command
• update CONTRIBUTING.md to refer to the script in bin

Update package dependency versions

Several packages have become out of date... update them.

Also: make sure that the redux-form-validation points back to the updated original repo instead of the @mcalthrop-namespaced repo.

Add flowtype support

Add i18n support

And implement it.

flow-bin 0.22 breaks build with JSON errors

Current version of flow-bin in the codebase is 0.21.0 because v0.22.0 is buggy: it does not process JSON files correctly, throwing an error.

Adding BrowserSync: Partial success

So I've had a crazy idea and wanted to add BrowserSync to your perfect boilerplate, here is what I've done:

const yargs = require('yargs');
const browserSync = require('browser-sync');
const express = require('express');
const webpack = require('webpack');
const debug = require('debug');
const config = require('../config');
const history = require('connect-history-api-fallback');
const webpackconfig = require('../webpack.config');
const webpackDevMiddleware = require('webpack-dev-middleware');
const webpackHotMiddleware = require('webpack-hot-middleware');

debug.enable('app:*');

const app = express();
const compiler = webpack(webpackconfig);

const log = debug('app:server');

log('Redirecting all other requests to index.html');
app.use(history({ verbose: false }));

log('Enabling webpack dev middleware.');
app.use(webpackDevMiddleware(compiler, {
  lazy: false,
  noInfo: false,
  quiet: false,
  stats: config.compiler.stats,
}));

log('Enabling Webpack Hot Module Replacement (HMR).');

// Run Browsersync and use middleware for Hot Module Replacement
browserSync({
  server: {
    baseDir: 'src',

    middleware: [
      webpackDevMiddleware(compiler, {

        // Dev middleware can't access config, so we provide publicPath in rather hack&pray kind of way  ;)

        publicPath: (config.paths.app.publicPath && config.paths.server.publicPath && config.paths.dist.publicPath),

        stats: { colors: true },
        noInfo: true
      }),

      app.use(webpackHotMiddleware(compiler))
    ]
  },

  files: [
    'src/*.html'
  ]
});


log(`Serving static content from ${config.paths.static}`);
app.use(express.static(config.paths.static));


const port = yargs.argv.port || config.server.port;
app.listen(port, config.server.hostname, () => {
  log(`Server is now running at http://${config.server.hostname}:${port}.`);
});

module.exports = app;

While this works unfortunately it does mess some of the css, specifically background and the the footer/login menu. In a way I'm actually quite surprised that it worked so well; perhaps you could give me your opinion about this, obviously I'm a big newbie here and I'm yet to grasp the whole thing. But with few pointers I can find my own way!

Update React Router + Redux usage

Possibly deprecate react-router-redux

Authentication support

Add at least one authenticated route with basic JWT authentication.

I'd propose having redux-auth available since it has good support for OAuth workflows (implicit grant / authorisation grant, etc), Email / username workflows (register, reset password, etc), but since we don't have a dummy API to go with this yet, I reckon we could use Auth0 Lock's free plan to authenticate.

Combine server files into one

The server that is used for running the app is split over two files:

• server/main.js
• bin/server.js

Simplify this so that there is a single file that is run to fire up the server.

Internationalise entire site

Much of the site has been internationalised, but some parts have not yet been done.

webpack: Failed to compile

I'm getting the following errors:

ERROR in ./src/components/DropdownProfileCard/DropdownProfileCard.scss
Module parse failed: C:\wamp64\www\chronit-frontend\src\components\DropdownProfileCard\DropdownProfileCard.scss Unexpected token (1:0)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (1:0)

for every scss file. Can you help me with it?

Thanks

Make profile fields editable

Data on the Edit Profile page is not currently editable (!), so implement a form to allow editing and saving of updates (but these will not be persisted to server, as there is no actual endpoint for the PUT request).

• basic field input
• checkbox
• radio button
• dropdown
• textarea
• internationalise placeholders
• input field validation
• react-bootstrap integration
• Reset button
• disable Update button when form pristine
• disable Update button on submission
• disable Reset button when form pristine
• disable Reset button on submission

Add sample unit tests

• add some sample unit tests
• wire in with npm
• update .travis.yml to execute them

Feature Propousal: Integrate Greenkeeper & Semantic-Release

I believe that OpenCredo has a lot to gain by adapting Greenkeeper/Semantic-Release combo (they complement each-other very well) and allow for more streamlined package maintenance as well as increase confidence and clarity in versioning.
I see OC as having the potential to become a standard by adherence to quality as one of its core principle.

The following will give you all the information.
The Greenkeeper Workflow
semantic-release

Given OC's is open source nature, I see no reason against this - another great feature.

Add dependencies badge to project

Add a badge (similar to the TravisCI badge) to the project that shows if dependencies are up to date.

Document contribution guidelines

Agree and provide guidelines for how to contribute to the project.

This should include things like:

• issue, branching and PR process – for example:
  • create an issue (if there is not already one existing)
  • create a branch
  • raise a PR against that branch once ready
• git commenting convention
• reference to coding conventions
• before committing:
  • command-line task to run
• anything else?

This could be seen a bit as overkill, but setting out processes like this is in itself an exercise in best practice.

Split form into separate components

The /profile/edit page is currently implemented as a single large form.

It would be more effective to break each input field down into a separate container:

• size of the form would be a lot smaller
• each form field container would then be reusable
• would be easier to test, as each component would have its own test

Make webpack import ./src/styles/*.scss as global

I see something tasty brewing here!

How could I be of an assistance gentlemen?

Create a new page that displays data fetched from server

Create a new page in the app that demonstrates how to retrieve JSON data from an XHR call, and display it on the page.

Server:

• create GET endpoint that returns static JSON
• consider creating a PUT endpoint to allow updates

Client:

• create new page
• wire in a call to the server to retrieve the JSON data and display it
• consider how to implement updates

Add a "Structure" section to the README

There are a few conventions in place in this boilerplate that might not seem evident on first sight. Having a short graph detailing the project's structure will help in this regard.

For example, the components vs containers convention is extended here with the src/pages/ directory (which holds components that live in routes).

I'll add this hopefully today so I'm creating this issue to track it.

Create CHANGELOG

Initial version will indicate status of the baseline.

Exclude npm test directories from flow config

Update .flowconfig to exclude test directory from npm modules.

There are two npm module dependencies that contain module tests; both of these contain invalid JSON (for testing purposes, so valid), which cause the current version (0.22.1) of flow-bin to fail:

• config-chain
• y18n

Add "Features" section to README

Add a Features section to the README that details some of the main features of this project.

For example:

• ES6/7
• Flowtype
• Redux
• react-router
• webpack
• Bootstrap
• SCSS
• foundation for protected pages
• react-intl

Document coding conventions/guidelines

Describe coding conventions used in this codebase.

This will include reference to:

• the airbnb ESLint rules (and local override rules)
• directory and file naming conventions
• algo más?

Add numeric input type to form

The form does not currently have an input with type="number", so add one.

This will also give us the opportunity to check the min and max validation routines.

Add Credits section to README

Add a Credits section to the README file to provide recognition for the codebase(s) that were used in constructing this boilerplate code.