Checking Out React

I started my journey at the React Tutorial Page. While reading the introduction and checking out the code example on Codepen, I then had the notion that seeing as it was a Tic-Tac-Toe game, it might be nice to do it more properly and include it on my website.

Once down this road I then decided it would be good to turn it into a mini project to find out more about yarn and webpack, as these compliment the React world and are the shiny new toys in front-end web development.

This first blog in the series is about the setup.

Notes on Yarn and WebPack
I have heard that Yarn is better than NPM as a package manager, it is faster and more reliable. Webpack is more complex/flexible than Grunt or Gulp as a builder tool but, like my personal favourite JSPM (through systemJS) it is an excellent JavaScript module loader out of the box. Webpack is much more popular than JSPM within the React community.

Back to Tick-Tac-Toe
So I used npm to install yarn, ran yarn init and then used it to bring down my dependencies React and React DOM. I was pleased to find that there is no difference in where the modules are stored - it is still in a folder called "node_modules". I was also aware that I needed to "transpile" the ES2015 React code into ES5 so I installed babel using the "webpack" option on the babel installation page.

npm install --save-dev babel-loader babel-core

Notice that this is based on npm, but this was no problem, you can just replace "npm install" with "yarn add" and the command "--save-dev" with "-D". This was all easy to find here.

Using Webpack to transpile ES2015 back down to ES5
After some research I have found that the best way to use Webpack with babel, karma and react is to use the following packages:

With this setup I was able to setup a simple "hello world" example. I will get into more detail with my next post.

Windows Azure and Node - Remember to specify the version

I kept finding that my back end code would subtly fail on something once deployed to an Azure site despite working fine in my own environment. Having hit the problem again recently, I again looked through the server logs to try to identify the problem assuming that again Node would be throwing an error over some very simple syntax.

Then I noticed the following:

"The package.json file does not specify node.js engine version constraints"
"The node.js application will run with the default node.js version 0.10.32"

This is old, in fact to put this into perspective the contemporary node change logs start from 0.12.0 which is the beginning of 2015. I had to go through their archive to find out where this version is from, which is October 2014!

Now I know, the solution is to specify the node engine that Windows Azure should use. e.g.

As soon as I had made this change my problems went away as you may expect. Looking at the latest "how to" guide on the Azure website for node development I notice that this features at step 5. However, for those who have legacy node websites on Azure, this is not so intuitive.