client side react

[chadxz]

Related to #25

This patch introduces a baseline for using React on the client-side. There is still work to be done to implement a Flux pattern for data flow, but the guts are here and working. I also intentionally did not setup hot-loading because that requires socket.io which has a native addon dependency, which can be a headache to get working on windows. We can attack that later, to make for a more fun development experience. The primary focus of this patch is:

• babel ES6 transformation of client-side assets
• whatwg-fetch polyfill automatically available to client-side js as fetch global
• React compilation on npm start

Some additional changes made:

• moved client-side js to lib/client to make the compilation step needed explicit
• moved server code to lib/server
• GET /restaurants now returns an id along with the name, to make React happy
• updated Dockerfile to use npm start instead of ENTRYPOINT and ENV

Further optimizations to the webpack config and the react development experience can be derived from the react-webpack-cookbook, or by looking at the myriad boilerplate projects you can find on github. For the time being, the development process is like this:

1. npm install to get everything installed
2. npm start to compile the javascript and start the server
3. make changes you want, then CTRL+C the server and re-run npm start

[chadxz]

That makes sense. Thanks for clarifying! I have not used Docker much so I'm not aware of patterns for use. I'll remove the Docker commit and add one that simply runs webpack to build the assets.

[chadxz]

@clarkda I've updated the PR. is npm run build in the Dockerfile okay for running the build step? The necessary tool, webpack, is not installed globally to the system, so if you don't use an npm run script, you'd have to either (1) install it globally (npm i -g webpack) and call webpack, or (2) call into the node_modules directory like ./node_modules/.bin/webpack which is messy.

[dustywusty]

Yeah, we'll need to add some tools to that image globally .. webpack, bower, and it would probably be a good idea to update npm as I think the version that comes with 10.38 is ~1.4 or something.

I had also been meaning to ask if you wanted to tick the version of node in that image up to a stable 12?

I'm not sure why I picked 10.38 in the first place ;3

On Wed, May 20, 2015 at 10:28 AM, Chad McElligott notifications@github.com wrote:

@clarkda https://github.com/clarkda I've updated the PR. is npm run build in the Dockerfile okay for running the build step? The necessary tool, webpack, is not installed globally to the system, so if you don't use an npm run script, you'd have to either (1) install it globally (npm i -g webpack) and call webpack, or (2) call into the node_modules directory like ./node_modules/.bin/webpack which is messy.

— Reply to this email directly or view it on GitHub https://github.com/codeforhuntsville/Frontier/pull/26#issuecomment-103925855 .

[dustywusty]

Also, everything looks :+1:

If you'd like, I'd be happy to submit a quick pr before lunch with some of the Docker changes I mentioned ^

[chadxz]

@clarkda I've been using 0.10.38 for the development, it's stable and works fine. It'll probably work with 0.12, but i haven't tested it. Updating the npm version seems like a good idea though :+1:

I removed bower as a dependency of the project for now, since we're not using it at the moment, so no need to add it as a global yet if you don't want (it won't hurt anything, though). If you do end up adding webpack as a global, i'm fine with it if you wanna change the Dockerfile to call that directly instead of using the npm run build script.

RE: Dockerfile PR, that'd be cool. #21 could use some Dockerfile love, too