Roadmap

[ericelliott]

Universal React Boilerplate

This is a universal JavaScript application boilerplate using Express & React.

Learn JavaScript with Eric Elliott

The Universal React Boilerplate was written for the "Learn JavaScript with Eric Elliott" courses. A series of courses to teach people how to build great JavaScript apps for production. Don't just learn JavaScript. Learn how to build amazing things.

Universal JavaScript

Universal (aka "isomorphic") means that it's designed to run a lot of the same code on both the client and the server. Typically that includes a lot of rendering and domain logic.

There are many advantages to building apps this way, but the primary advantages are:

• Cross-functional teams. Since everything is written in JavaScript, it's easier to build teams who know how to work on both the client and server sides of the app.
• Write once, run everywhere. With the exception of a few library substitutions and browser polyfills, the code is shared, which means you have to write about half the code you'd write working on a non-universal app.
• More productive developers. Since the app is more consistent across the stack, there's no context switching when you need to maintain application behavior on both sides of the stack. Write the behavior once, and you're done. Context switching slows developers down significantly.

  Roadmap

I'm planning to put a lot of love into this and make it an essential resource for anybody interested in building production Node and Universal JavaScript applications. It's already very useful as-is, but we've been rewriting a lot of these things over and over again for every app, or searching through the haystack that is npm and spending too much time on tech selection instead of knowing what the best, most well-tested solutions are and running with them.

This boilerplate will eventually demonstrate a very simple production ready application, including:

• [x] Unit tests with tape & faucet
• [ ] State management and time-travel debugging with Redux
• [ ] Route and render with react-router + redux-router
• [x] Client bundling with Webpack.
• [ ] Client unit tests also need to be validated cross-browser. smokestack with Sauce Labs
• [ ] Functional testing with selenium-sauce on Sauce Labs
• [ ] Logging with bunyan-request-logger
• [ ] Configuration management with qconf
• [ ] Error handling with express-error-handler
• [ ] User sign-in flows with Passport
• [ ] OTP auth with Authy (passwords are obsolete)
• [ ] Auth tokens with json web tokens
• [ ] User authorization for feature access
• [ ] i18n
• [ ] Data input validation
• [ ] Robust feature toggling with multivariate testing support
• [ ] HTML5 form validation (h5v2?)
• [ ] CORS
• [ ] XSS prevention with Lusca
• [ ] Security audit built-into automatic build validation

In other words, everything you'd want to reuse in most production-ready applications -- all done for you using years worth of tried and true best practices.

Help wanted

Let me know in the comments if you'd like to help with any of these items.

Courses

Students will get a series of short videos, lots of interactive lessons explaining concepts in-depth, the ability to help and learn from each other, and a lot more.

[ericelliott]

Yep. Everywhere I've pushed Node into production, we've had nginx & or haproxy, or both set up to reverse-proxy to our Node instances -- even for my smallest personal website deployment, I used nginx as a reverse proxy layer so I could route to different services easily.

[mycall]

Is it possible to have multiple versions of the boilerplate? From most simple to advanced.

[ericelliott]

It's not only possible, it's likely. =)

[vasco3]

What are we considering for CSS? I've used https://github.com/sass/node-sass successfully. or maybe we could leverage the webpack css loader

[vasco3]

What about code coverage with codeCov.io ? :smiley:

[nkbt]

@vasco3 I prefer coveralls and use it for all my projects. Works well, but requires some minimal extra manual setup (set ENV vars in CI)

[vasco3]

@nkbt does Coveralls use xml like CircleCI or json? I had that discrepancy with CircleCI + CodeCov eg. https://github.com/vasco3/Oracul/blob/master/circle.yml#L18-L19 btw great job with the tap-xunit + CircleCI implementation

[nkbt]

Thanks, @vasco3! Yep it does. Not XML, but normal lcov.info

- cat ${CIRCLE_ARTIFACTS}/coverage/lcov.info | ./node_modules/.bin/coveralls

https://github.com/nkbt/react-component-template/blob/master/circle.yml

I use || true so coverage report does not break build in case of service is down or something. But it could be removed of course

[vasco3]

@nkbt how do you like isparta over babel-istanbul?

[nkbt]

Used isparta before babel-istanbul was there, works well, so I feel no need to swap it to something else for now.

[gacosta89]

Hey guys, do you plan to include Redux in the project? If that so, I can help you including redux-devtools and the config for react hot reloading and reducers hot reloading.

[mycall]

react-kickstart uses hot-module-replacement (babel-plugin-react-transform + react-transform-hmr)

[ericelliott]

Yes, I plan to use Redux + HMR.

[nkbt]

HMR is added by #67

[gacosta89]

I think for react HMR you need this babel plugin: react-transform-hmr, with this config: .babelrc.

[nkbt]

@gacosta89 that is how it is done in #67 =)

[gacosta89]

:( sorry.

[nkbt]

@gacosta89 no worries :ok_hand:

[guidsen]

What about writing a test for the reducers that have been added recently? Would be a great feature to show the users a good example on how the reducer can be tested (simple functions). Might have some time for it this week.

[ericelliott]

What about writing a test for the reducers that have been added recently? Would be a great feature to show the users a good example on how the reducer can be tested (simple functions). Might have some time for it this week.

Sure. Please use tape and keep them simple.

[gacosta89]

Hey guys! what do you thing of i18next for translations? I used it along with react-i18next in production. It has a very nice defaults and overrides system for keys.

[nkbt]

We used it in our prod app and moved to node-gettext for several reasons (one of those - inability to do plurals in-place, so we had to have en.js file, which is essentially wrong, and overall awkward syntax for templates and plurals). In general I would recommend to stick to a standard implementation - gettext. If you want some friendlier gettext solution, check 'jed' On Tue., 18 Oct. 2016 at 03:42, gacosta89 notifications@github.com wrote:

Hey guys! what do you thing of i18next http://i18next.com/ for translations? I used it along with react-i18next https://github.com/i18next/react-i18next in production. It has a very nice defaults and overrides system for keys.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cloverfield-tools/universal-react-boilerplate/issues/4#issuecomment-254262615, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKsoDPknB8KHkh94sxlmLriDKDioHcIks5q06VagaJpZM4Dd88f .