bericp1 / boilerplate-react-reflux

A small and simple boilerplate for a React+Reflux

Brandon Phillips

Welcome! I'm Brandon. I've been writing (mostly web) code for about a decade and I currently work primarily on full-stack web app development @ Vivian Health.

We're hiring!

boilerplate-react-reflux's Issues

Include auth system?

Catch stream errors from browserify and just ignore

Include webstorm file templates? (If even possible to export from webstorm)

Include scss autoprefixer

Add JSnoX?

Should try out in project and see how well it works and how easy it is to use. I would feel more comfortable without XML in the middle of my JS.

Clean dist on build or serve start

Watching server files and reloading the server when they change

You'll need to look into requireing w/o cache so that server.js can be rerequireed properly

Include mongoose?

Improve example styling

Tests!!!

Break `sever.js` into `index.js` or something else

index.js will export a function that takes two arguments, the express app first and a done callback second. This callback must be called to finish starting the server.

This function will be called after the database has connected.

Naming wise, perhaps server.js can be renamed to index.js since it is the entry point for the entire web app and then this new file can be called server.js.

The benefit to splitting up server.js is that code that shouldn't be changed isn't mixed with code that should be changed or built on top of. It's much nicer and cleaner to have the custom routes and whatnot setup in a seperate file from where the server is pre-configured, database connection is fired up, etc.

It may be necessary to split the form for the mongoose example into a seperate store

For example to isolate errors separately and to retain state between route changes. The view-controller can still listen to both stores so its loading state can listen to the states of both stores

Include bootstrap?

Refactor/abstract out tagged-responses system into lib

Support SASS w/ watching in `$ gulp serve`

Privatize `this.data` in stores and create getters/setters

This may be accomplished by using a variable local to the module

Split store methods related to API into lib module

There are currently some methods I'm using repeatedly related to retrieving data from an API and that I can see using frequently in the future. They should be pulled into an external module in public/src/lib so that I can do something like the following:

var createAPIStore = require('create-api-store'); // `public/src/lib` has been added to the browserify search paths
var actions = require('./actions');
module.exports = createAPIStore('/api/items', {
  init: function(){
    this.listenTo(actions.reloadItems, this.reload);
    this.listenTo(actions.deleteItem, this.delete);
    this.listenTo(actions.addItem, this.add);
  }
});

Modify tagged-response system within views to differentiate types of responses

i.e. store different tags for each different type of action that the component can perform. The list only performs one, the item only performs one, and the form only performs one so this hasn't been an issue yet but it will be.

Add "Getting Started" section to README

Split this repo into the boilerplate and an example project using the boilerplate