Getting Started

React and CoffeeScript

Before we can start working on any views, we need to install React since that’s what we’ll be using instead of Blaze.

Adding libraries to Meteor is super simple:

meteor add react

We personally prefer CoffeeScript over JavaScript due to the readability of significant whitespace.
There’s a popular opinion at the moment that CoffeeScript is obsolete now that we have ES6 and Babel.
I disagree because I think browsers will eventually support WebAssembly.
Once they do we’ll see even more JavaScript alternatives.

meteor add coffeescript

Now we’ll need to do some standard tweaks in order to have React and CoffeeScript play nice without excessive amounts of syntax.
First we’ll create a lib folder and add a component.coffee library to it.

mkdir lib
touch lib/component.coffee

In component.coffee we’re going to add a function that we’ll be calling instead of React.createClass

Notice the @ symbol used to declare our Component object?
CoffeeScript places our code in a closure so as not to pollute the global namespace.
In Meteor we need to attach our object to the global namespace using this (@ = this.).
This is a little counter intuitive compared to CommonJS style requires, and maybe some day we’ll have a better alternative.

For now @Component makes our object accessible throughout the application.

Project Structure

Now is as good a time as any to setup our basic structure for the application.
Meteor has a convention where any code that’s placed within a directory named client will only run on the client.
And naturally code in a directory named server will only run on the server.

We want the following directories under the root of the project:

lib: Common library functions. These are loaded before the other directories.

client: Code that should only be run on the client (browser).

server: Code that should only be run on the server.

public: Only served to the public. We’ll put our robots.txt and images in here.

Now we need to attach our React views.
Create a new CoffeeScript file in the client directory.

vi client/index.coffee

In this CoffeeScript file we load up our React views and attache them to the DOM.

12345

Meteor.startup->React.render(App({}),document.getElementById'app')

We’re referencing an object called App within the Render method, so we need to build that.
Create a new CoffeeScript file in the client directory for it.

vi client/app.coffee

Our new app.coffee is going to hold our top level React component code.

123456

{h1}=React.DOM@App = Component.createrender: ->h1{},'Teh Gosu!'

We’re keeping it simple. All we’re doing is rendering an h1 tag with the text Teh Gosu!.
Notice the @ symbol prefix to the App declaration.
Again this is because of CoffeeScript’s automatic closure and the fact that Meteor needs the object to be on this to be accessible outside the file.

At this point we should have a working React + Meteor application. Run the server with:

Lately I’ve been using ReactJS a lot to build rich user experiences on the web, and it’s been absolutely great. A huge improvement over AngularJS in my humble opinion.

The only ugly spot with ReactJS is JSX. I can see the appeal of using declarative HTML in templates for readability, but having switched to HAML (and Slim and Jade) long ago, writing HTML feels like a step backwards.

Luckily, using CoffeScript for my ReactJS components and eschewing JSX entirely, we can accomplish a syntax that’s very similar to HAML / Slim / Jade. If you’re not a fan of CofeeScript, HAML variants, or significant whitespace, there’s little chance I’ll be able to convince you otherwise. However if you are a fan of any of those, then it’s worth checking out.

If you do opt for the straight CoffeeScript route, then there are a few gotchas to keep in mind. If you’ve been using CoffeeScript for a while, then they’re pretty obvious, but can cause grief for newcomers.

Gotcha 1: Optional Curly Braces

CoffeeScript allows you to omit Curly braces on hashes. This can cause readability issues for the next person who comes along to read your code.

Ultimately if you are going to use CoffeeScript for your ReactJS components instead of JSX then it’s probably a good idea to agree upon some conventions with your team on when braces and commas are used. My preference has been to use braces for single line hash assignments, and I’m considering enforcing braces for multiple line attribute assignments w/ React to better separate them from the next element.

For starters, we’ll need a linux box in the cloud. For the server we’re going to go Digital Ocean since it is one of the most affordable options at the time of this post. However, the steps are essentially the same with other hosts like Linode and EC2, so definitely check them out too.

Sign up for an account at Digital Ocean and then create a 512MB droplet running Ubuntu 12.04 x32. If you’re not sure about the hostname option, a good choice would be something like pair.yourcompanydomain.com. Make sure you chose a region that’s close to you and your team to minimize latency.

At this end of this tutorial you can shut you droplet down if you aren’t going to use it, and it’ll only end up costing you a few cents.

Once you’ve created the droplet, you should receive an email from Digital Ocean with your new boxe’s IP address and credentials. For the rest of this post I’ll use a fictional IP. Just substitute the IP you were given as needed.

Open up a terminal if you don’t already have one up and follow along with these commands to setup and install the basics.

Now we have a fairly secure server with our pair accounts using password-less access and it’s time to setup the pairing environment. We’re going to use wemux which is backed by tmux to manage the sessions.

I recently ran into an issue with RubyMotion where I couldn’t build to a development device without explicitly setting the provisioning profile in the Rakefile. Not only is this annoying, but it’s a big problem for team development because you’ll always want to check your Rakefile into source control and each team member would have a different Rakefile.

So I started hunting for a solution.

Official Documentation is Misleading

The RubyMotion official project configuration documentation states that it look for and use the first provisioning profile it finds on your computer. This is false though, at least when you have multiple profiles, because even if each of your profiles contains the device UID you’re building to, this still won’t work.

Existing Solutions Insufficient

The existing solutions are simply to explicitly refer to your provisioning profile in your Rakefile. That’s OK for solo development (but still annoying), however it’s not a good solution for team development.

My Solution

After a little light reading I discovered that the RubyMotion build will check for a default profile named “iOS Team Provisioning Profile”.

So we simply need to create a new provisioning profile via the iOS provisioning portal named “iOS Team Provisioning Profile” and containing the device(s) we want to be able to run development builds on.