Live gut reactions to learning Ember.js

I am starting on a new project that uses Ember.js.

I started learning it from scratch a few days ago. Thought it would be a good opportunity to log my gut reactions while I find out how it works.

My main term of comparison will be React.js, which I started learning in about February 2015. I have spent a decent amount of time working with it. Far less than on jQuery-based projects in the past, but still. I also know a bit of Angular 1, so that may come up too.

I will go for free-associative, bullet-list, initial reactions for this post.

  • Official website is organized and pretty enough.
  • Really easy to download and have a local server running with a blank app.
  • No webpack. I like that.
  • ES6. Great.
  • Official tutorial does tests. Awesome.
  • Tutorial is very clearly written. Can’t compare to what I came across when I started with React.
  • Handlebar templates. I don’t know about that. Better than jsx perhaps? I miss jade, slim, wonder if it can work with something like that.
  • Bower? Not happy to see that.
  • All package names seem to start with ember-cli. Welcome and scary at the same time.
  • What’s the difference between a controller and the other entities, helpers etc? Still pretty foggy at this point.
  • Easy to install Stylus for CSS. Heard about “ember pods”. Will investigate.
  • Extremely easy to deploy something crude to Heroku, even without doing anything about the env.
  • Oh gosh, there’s an ember package to load Google Fonts.

Notes on deploying Webpack in a Phoenix application on Heroku

As of today, there’s no Heroku buildpack specifically built for deploying Phoenix and Webpack. Having found no consolidated place to learn how to do it, here’s what I did.

First, make webpack run in your local environment. This link explains it well.

Make sure to comment out /priv/static in your .gitignore file.

If you haven’t, add the following buildpacks to your heroku deploy.

# Set the buildpack for your Heroku app
heroku buildpacks:set https://github.com/gjaldon/phoenix-static-buildpack

# Add this buildpack after the Elixir buildpack
heroku buildpacks:add --index 1 https://github.com/HashNuke/heroku-buildpack-elixir

Add a file called compileto the root folder of your app, and add the call to webpack:

ENV=production node_modules/.bin/webpack

Note that ENV=production is optional and should relate to your webpack configuration.

Voilà.

React.js, Facebook JS SDK and a costly little mistake

Last week I spent much more time than I ever wanted implementing Facebook login in React.js.

As it often turns out to be, one mistake cost me about 10 hours net of investigation, and if you don’t have time to read further, here’s what was wrong: I had added all my <script> tags inside <body> in the html, and then used <body> as the element to replace when rendering my main React component.

That was it. But what about that mistake is making me stop and write about it?

First: my app worked perfectly for a long time just as it was. Weeks. In the beginning of the project I was switching back and forth between two different build systems, and when I decided on one I must have copied the main React component and nothing pointed out an error.

Second: Facebook login kind of worked perfectly in localhost. The only strange thing I noticed was that, as I loaded the js sdk into the html, the most important sdk method, FB.init, was never found.

Since I am no React master at this point and Facebook provides no documentation on how to integrate FB login to React, even though they’re all made by FB, I had many possibilities to investigate. And lo and behold, by moving the FB.init call to the React component inside componentDidMount, everything about the login worked in localhost.

When it came to the staging environment, however, things got weird. My app would not get the login status on load, but on clicking the login button, the modal dialog would open. Sometimes the window would come up blank, sometimes it would prompt for login and then never close, and many other different outcomes.

Since most recent blog posts on Facebook login deal with difficulties with OAuth settings, my investigation went that way, and there it stayed for a long time. No warning or error message ever gave me the slightest clue as to what I was doing wrong.

Thus a mistake that arguably should have made my app break on the very first run ended up taking many hundreds of runs before the bug was caught.

———————

Follow up:
React 0.14 warns against this.

Moccato

In July and August 2015, I spent about 140 hours working on Moccato.

They are a subscription service for Nespresso pods. Apparently Nestle’s patent or rights for exclusivity recently expired, and Fabrizio Serra, formerly from ChefsClub, took up on the opportunity to have high-grade Brazilian coffees delivered to people’s doors.

They had run into difficulties with the frontend, even though they had been able to launch the website in some fashion. When I took up the work, they had a solid backend engineer, Dimas Cyriaco, a mostly complete and excellent visual identity developed by my brother’s Plau (who evidently were the ones to recommend me for the work), and were ready to begin packaging and shipping coffee all over Brazil.

Moccato is built on Ruby on Rails. Earlier, they had attempted to do an API-only backend in Go, but it was not successful. They decided to go with Rails, and what was initially an independent API client was integrated into the new Rails app.

They managed to make it work somehow, but the code base was highly impractical to iterate upon. The home page was linked to static css and js files, as were about 4 or 5 other pages, all to their own assets which were not at all using Rails’ asset pipeline. Thus, changing a mere style would involve finding it in any of up to 5 redundant stylesheets, and then making sure that style wasn’t used anywhere else.

Once I had that diagnosis, it was clear we had to move everything into the Rails asset pipeline, remove all duplicity, and only then look into giving the frontend conceptual coherence. Classes were named completely different from one file to another, and the DOM structure had 3 or 4 different versions.

The reorganization was not particularly difficult to do, but it’s remarkable how laborious it always is after something is in place. It’s impossible to stress enough how much more economic it is to have a very good programmer from the get-go. Also, of course, how it’s never very easy to get one.

I converted all .erb templates to .slim. Yes, Slim is much better in my opinion. If one is a Ruby programmer, Slim is the most Ruby-like templating system there is. It’s concise in the same way Ruby is.

I also converted most Javascript to Coffeescript. Same idea here: it’s a Ruby project, so it’s great to use a similar mental model for everything.

The pleasure of working with Slim and Coffeescript is like night and day when compared to xml-based templates and curly-brace-semi-colon-purgatory JS 5. Also they’re far more productive and, performance-wise, pretty identical.

I was able to introduce a few things which I learned from working with guys at Code Miner, such as using Pivotal Tracker (better than Asana, which I had been using prior, and possibly not as good as Sprint.ly, which I want to use soon) and certain Github project management procedures ranging from using pull requests even if working alone on a repo (pretty extreme, I know) to subtle commenting etiquette and markdown styles.

Perhaps most importantly, I learned and used Airbrake for the first time. It’s an integration that notifies you of exceptions via email, Slack or other channels. It has a ton of possibilities, and it’s one of those things you just can’t live without after you experience it. Another one I was not able to delve much into, but seemed pretty powerful, was RD Station, as far as I know a Brazilian digital marketing engine that seems really well done and which I will definitely look into with more detail.

The end result was a desktop website that is free of extreme layout breakages, much more consistent visually, and much closer to being considered responsive. Also, I was able to build a mobile version, which really should be everyone’s first consideration from now on — instead of desktop —, as much as I personally prefer to use and develop software for larger screens.

I wish I had more time to fine-tune the designs and work on user admin pages, but that was not to be. It may, however, happen in the future, and I will write about it if so. Many thanks to my brother Rodrigo, to Dimas for being such a great work partner, to Fabrizio for the trust and to the whole team at Moccato. I wish you much success.

React.js and software workarounds

The amount of conceptual compromises React.js either addresses or introduces is very high. That, however, is typical, especially in a browser environment.

This introductory talk explains the basic design decisions that led to React.js.

Although the video is a bit old, it’s also surprising to hear, at the very end of the video, that the presenter has no idea whether React will be used for Facebook mobile on browsers. Reminds us of Microsoft.