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:

• Unit tests with tape & faucet
• State management and time-travel debugging with Redux
• Route and render with react-router + redux-router
• 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.

[zebulonj]

@ericelliott I'd like to help. I'm currently in the midst of a similar exercise as I work to break a legacy monolith down into micro-services... and as my first attempt at an isomorphic application I'm making up a lot as I go (so I don't pretend to have a lot of clear answers to offer). At the moment, the bit I'm most interested in is the isomorphic templates and rendering.

[ericelliott]

I have purposely not baked in a template system, but I'm considering changing that, using Minimongo, Track, and Blaze to do rendering on both the server and the client. It's a bit of a moving target, though, because the Meteor project doesn't seem to have any interest in maintaining an npm version of those libs.

Alternatively, we could show an example using React and Flux. Maybe those example implementations could be in a different repo which we link to from this one?

I'd love to hear your thoughts.

[capaj]

@ericelliott do you really think browserify is the way to go get trully isomorphic JS? To me it seems JSPM is more up to the task, because it allows for any kind of modules, not just CommonJS. Much more easy to develop with, because there is no need for build steps.

[zebulonj]

Regarding rendering... I'd lean toward React and Flux.

[alexbasalyga]

@capaj I don't think the goal here is to use a technology that supports every kind of module, but simply to use the best technology available (in terms of simplicity of use and how well its maintained) to allow the use of npm as both the server and client package manager. JSPM very well may be the best tool for the job if the job is packaging CommonJS and AMD modules beside each other for the browser, but I think the job at hand is smaller in scope.

[ericelliott]

@capaj We're interested in sharing the same code with the same source files authored in a single module format. JSPM may be a great solution for using ES6 modules in the browser, but I think it's a better fit to use Node style modules for code that is targeted at both Node and the browser, today. (That may change in the future, but it hasn't changed yet).

[ericelliott]

@zebulonj That combo definitely has the mindshare right now. 👍

Should we be looking at trying to use JSX? Mixing markup into my JavaScript rubs me the wrong way.

I thought it was a great idea when PHP hit the scene. We all know how that played out... It was a bad idea then, and I'm not sure that anything has changed.

Also, if you're mixing markup into the JS, it seems like that puts an artificial limit targeting the output only to the DOM. IMO, one of the most attractive things about react is that it can target more than just the DOM...

[zebulonj]

@ericelliott I'm opening a new issue for this conversation about rendering (#13).

[h02e56]

@ericelliott thanks for spread your knowledge.:)
I've learned just seeing initial code. I would like to help someway.
About project, i am more "frontend" but i like going deeper on server side. I have played a little with express, although nowadays i like use tiny modules instead.
About put the scripts on place i use to put them on the same node_modules folder, and now i feel weird having 2 node_modules folder. for sure is is just a matter of habit.:)
I could give a hand with i18n , or routing with page or client bundling(think is solved)

[ivanoats]

"Full-featured build system" - Grunt, Gulp, or stick to NPM scripts? What do you think of Gulp? I could help with that.

[ericelliott]

h02e56: RE 2 node_modules folders -- this solution is much better than scattering relative paths all over the codebase that make refactoring harder than it needs to be.

@ivanoats npm is a placeholder until we have a consensus for Cloverfield. PLEASE DO implement a gulp build in the todotasks repository. See the discussion in the Cloverfield repo.

[terakilobyte]

I'd love to help on this project, and am looking forward to your courses. As an aside, how do you feel about babeljs?

[ericelliott]

Babel and similar projects that let us use future language features are awesome. Bonus if it exports node-compatible modules so you can require() with Node and Browserify.

[ericelliott]

By the way, did you see the announcement? The first course has landed! We're letting students in and adding content. We're off and running. =)

[ivanoats]

@ericelliott I'd be happy to help but to clarify your request to implement gulp - isn't it already here? https://github.com/ericelliott/todotasks/tree/master/implementations/gulp

[ericelliott]

Oops! I completely forgot. Do you want to look it over and raise any issues or suggestions in that repo?

For now we're sticking with npm here unless / until we come to some consensus in Cloverfield. If you have anything to add to the Cloverfield taskrunner discussions, please add them.

One thing I like about a gulp implementation is that we have a better potential to make all the tasks completely cross-platform. I know we have some windows compatibility issues it might help resolve.

Then again, Broccoli might do the same thing for us, and it may have some advantages over Gulp... but the Broccoli vs Gulp vs x debate belongs in the Cloverfield discussion thread, so we can concentrate on isomorphic / Node / Express issues here. =)

Do you want to create a gulp implementation branch here that reproduces all the functionality in a way that is more Windows friendly? I might be willing to merge it if it clearly works better than our current implementation.

[h02e56]

@ericelliott node_modules i was meaning putting them inside root node_modules
node_modules/app/server
node_modules/app/client

[ericelliott]

@h02e56 We don't put them into root node_modules because if you commit those to your repository, any time dependencies change, you get a ton of vendor noise in your pull requests, and code review becomes a bit of a nightmare.

I personally prefer that you make it easy to rm -rf node_modules if anything goes wrong with dependency updates. If you mix your modules with vendor modules, make changes in your modules, forget to commit, and then update dependencies, and something breaks, it can be hard to figure out what the working state was.

If your modules are not mixed with vendor modules and something goes wrong with a dependency update, you can safely rm -rf node_modules && npm install to get back to your working state -- even if you've made a bunch of changes and haven't committed them, yet.

That said, you should still commit often. ;)

[ericelliott]

Also, putting them in app/node_modules means that instead of typing require('app/lib/foo'); you can just type require('lib/foo');

Just a few keystrokes per require, but it adds up.

[h02e56]

👍
"That said, you should still commit often." thats a true "como la copa de un pino" as we say here

[SOSANA]

are we using a flux pattern with react.js?

[nkbt]

Until there is a Relay, Flux is the way to go if you as me.
I've just rebuilt one of our angular modules during this sprint and first have done it without Flux at all. The code was boilerplaty as hell. Then added Flux and cleaned up to 30% of that mess right away. So I can't see any reasons not to use it as a default way to tackle data/app-state. No matter if it is React or angular.

Important question is if this particular boilerplate targets higher scope then just low-level-no-shared-state reusable React component or wants to handle more complex components? @ericelliott what's your idea on this?

[SOSANA]

@ericelliott @nkbt have you guys checked out https://github.com/optimizely/nuclear-js ? its a Flux architecture built with ImmutableJS data structures.

[nkbt]

Sure thing. Check Redux by Dan Abramov, please

[ericelliott]

@vasco3 Express has officially supported gzip middleware:

var compress = require('compression');

app.use(compress()); 

I think if we're going to include compression, that's how it should be done. It's easy to see @nkbt's perspective, too, but I don't see the harm in adding two lines to the sourcecode. I do see the harm in ignoring gzip altogether. If we don't at least mention it, people will forget about it. And that would not be good. =)

[ericelliott]

I don't feel strongly about it, so I'd accept a PR that adds those two lines, or I'd accept a PR that adds a mention in the README and links to detailed instructions for both nginx and haproxy.

[vasco3]

will the compression middleware be compressing on every request?
Or do we still need to compress on npm run build?

On Tue, Aug 4, 2015 at 4:08 PM Eric Elliott notifications@github.com
wrote:

I don't feel strongly about it, so I'd accept a PR that adds those two
lines, or I'd accept a PR that adds a mention in the README and links to
detailed instructions for both nginx and haproxy.

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[therealklanni]

It makes more sense to me to do this at the nginx level. It's probably faster at it, too.

[vasco3]

@therealklanni do you mean using nginx as a proxy for Node express server?

[vasco3]

What about cache busting?

[nkbt]

@vasco3 yes. Proxy for node server.

[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 ? 😃

[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 👌

[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
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKsoDPknB8KHkh94sxlmLriDKDioHcIks5q06VagaJpZM4Dd88f
.