Five things I learned writing an Ember-cli addon

I recently talked about how to use EmberJS with the ArcGIS API for JavaScript. I also talked about how this was done using ember-cli and provided via an addon I wrote called ember-cli-amd. This was a great learning experience and I thought I would share some of my big takeaways from this project. The Ember-cli docs do provide a great starting point on developing addons. I was also able to find some great intros on the subject while searching. So here are five things I learned while writing an addon.

1. The Ember-cli addon lifecycle

One of the big challenges I had when I first started was just on where in my addon could I write code to accomplish my task. I would see mention of a few methods here and there, but it wasn’t until I went back to the github repo that I found reference to the addon hooks document. This document should be your main ember-cli addon reference. It list all the methods that you could hook into for your addon. It even list some examples where a hook was used in a relevant addon. This was great, but the order the hooks are listed isn’t the order things are executed. You could definitely make out by the names on when certain things happen, but as a newcomer, I wanted some firm footing. So just started throwing out log messages everywhere until I figured it out. Here are the main hooks you should know in order:

• setupPreprocessorRegistry
• includedCommands
• included - probably most important
• treeFor - can vary depending on the trees analyzed
• config
• postprocessTree
• preBuild
• contentFor
• postBuild

Some of the treeFor calls can be sprinkled throughout before you get to the preBuild, but if you look at the documentation, it occurs for different types. The steps you would probably be most interested in is included as this is where you access to the Ember app and lots of other information about the application being built. The postBuild method might also prove useful as this is where you can get the temporary directory name compiled files are stored before they get copied to the assets folder. Don’t bother trying to write to the assets folder yourself, it will just get overwritten.

So if at any point you get stuck on how to accomplish something with your addon, refer to the addon hooks document.

2. Broccoli

I learned how to spell broccoli. What is Broccoli and why should you care? Broccoli is the tooling used by the Ember-cli. Broccoli is similar to Grunt or Gulp. What it mainly does is provide a tree structure of your application during the build process. I suggest you watch this video to get a better understanding.

It may not be necessary to know Broccoli in and out if you are writing Ember-cli addons, but it definitely couldn’t hurt. In particular, you may find you need to write a Broccoli plugin to do some low-level stuff in you addons. I found I had to make a pull-request to a plugin to get some functionality I wanted, and thanks to the author, I even got a better understanding of writing the plugin to fit with how some other Broccoli plugins were written. So my advice, at least get familiar with Broccoli and the plugin ecosystem.

3. Esprima

So you are writing an Ember-cli addon and you find you need to do some sort of code analysis, such as find where AMD modules are going to be needed. How would you go about parsing that code? Well, a good method to do something like this would be with Esprima. It’s important to note, this may not be required for writing Ember-cli addons, but it was something I learned while doing so. Esprima turns JavaScript code into an abstract syntax tree, which is basically a large object with nodes that represent your code. You can find functions, variables, inject code, go nuts with it. It’s also great for finding where known AMD modules are being imported into an application. Import? Did I forget to mention that all Ember-cli code is written in ES6 or ES2015, whatever you want to call it. That means modules are import‘ed. Esprima is really, really cool to play with. It’s much easier than trying to parse your code as a string. I mean it.

4. Blueprints

So blueprints are basically templates you can write as Ember-cli addons. Say you want to have a reusable take-over-the-world button and you want to share this button with your evil companions. You could create an addon with this component built in. Evil geniuses that install this addon now can use this button in their own applications. For more not-so-evil details, check out the docs and I found this blog post useful.

5. Ember

I’ve said before that in the past, I have had issues grasping Ember. It was probably one of the only frameworks that had a tough time clicking for me. Well, I can tell you, there is nothing like attempting to write an addon for a tool you hardly know for a framework you don’t understand to put you in the trenches and sink or swim. I think after reviewing tons of source code and documentation, using Ember-cli has definitely helped me grasp the Ember way of doing things. Do I think it’s or everyone? No, but I do think it definitely has it’s place in some application development. I’m still trying to really learn the innards of Ember, almost line by line to get a better understanding of how some things are done, so I am far from an expert.

All in all, I learned a lot while writing an Ember-cli addon and I think anyone interested in Ember-cli could benefit from the same process. If everything were easy, nothing would be any fun and that’s what makes all this stuff interesting!