Series: Journey to Ember-CLI

Transferring to Ember App Kit

Published on Apr 24, 2014

How to transfer your application into Ember App Kit.




Welcome back to Ember Sparks. This is part two of our three part series on Ember App Kit. In this episode we'll be transferring our old application to Ember App Kit with the goal of making it function exactly as before. To do this we'll have to mold our application to App Kit's file structure, as well as make a few tweaks to make it work. We'll start our investigation of Ember App Kit by looking at index.html which is the first thing you load. It uses script tags to pull in files. You can see here that it uses the variables test and dist, in order to determine whether the environment is test development or production.

For this screencast, we'll be working in development. So it loads some environment specific files which are currently mostly empty, and then it loads a bunch of vindert files. These are the ones that we got via bower. Then we load something called app.js and something called templates.js. Note that even though there's an app.js file that we can edit, the one that we're loading is coming from the assets folder. This is a temporary folder generated by grunt when you run the server. So we can save our code in a bunch of different files, and then grunt will concatenate them all for us into these two files. How it does all this is determined in the grunt file. If you're interested in how all the grunt magic happens, check out this great series of blog posts by Toren Billups. The link will be in the show notes.

To help grunt perform it's tasks effectively, we use the ES6 module system. It's under development, but is rapidly gaining support. Especially, within the Ember community. When we want something in our file to be accessible elsewhere, we use the export key word. Ember App Kit currently only supports one export per file, the default export. So we always use the default key word right afterwards as well. Then, once we've done that, we can import the file elsewhere. Like we do up here, and then we pull out the thing that was imported and give it a name. In this case, resolver.

Ember also does some magical stuff using the thing we exported in the file name. Let me show you an example. Here's the application adapter in our old version of application, and here's our application adapter that Ember App Kit generates for you. Basically we've replaced app.application adapter equals with export default. The file structure is what tells Ember App Kit that it will be app.applicationAdapter since the file path is app/adapters and the file name is application.js. Ember App Kit takes that path, rearranges it appropriately, and comes up with the name.

Let's transfer one of our own Ember objects. We'll do the post route. So we create a file in the route's folder called posts.js, then we paste in our code. And because of the file name, it'll already know that it'll be app.postroute. So we can just do export default, and Ember App Kit will take care of the rest.

Now, off screen, I'm going to repeat that for every other Ember object. So I just did all that. All the job's script files are transferred. However, a few things needed to change in order for the app to actually work. The first is in the post model. We couldn't export directly because we had to add on fixtures. So we defined it as a post, not, then we add fixtures to the post, and we do it using reopen class, and then defining fixtures property on the class.

The second is in our handlebar's helpers. Previously, we were just putting the name as the first argument to helper, with the ES6 module the names going to be specified by the file name in the path. So we'll switch using make bound helper which returns the helper which we will then feed to the exporter, and the file path will determine how Ember sees the name.

Now we'll put in our dependencies, moment and showdown. We'll install them using bower install, capital S, and then the name. Let's go ahead and first search, see what exactly the moment one is called, and it looks like it's just moment. So we do bower install -S moment. And now we'll save it in our bower.json file, as well as save the files in the vendor directory. We'll go ahead and do the same thing with showdown. Then we'll have to go into our index.html and put in references to the vendored files. Here moment defines a global function, global moment function. So we don't need to do anything there, but for showdown we'll have to go into our helper and create an instance of the showdown converter. In our previous one that was done outside of the helper.

Next, we'll deal with our templates just like with the Ember objects, Ember App Kit will use the name of the file and folders to figure out what to do with the template. In this case, the file and the folders correspond to the ID here. So here, if we wanted to copy this one over, then we would have it in the post folder and in index.handlebars. Let's go ahead and do that. So we'll go into the templates, and we'll make our posts folder, and put in a file that we call index.handlebars. I'm going to go ahead and take care of the rest off screen. Finally, we'll just copy over our routes into our routes in Ember App Kit, and then our application is fully assimilated into Ember App Kit, and it is indeed working wonderfully.

However, you notice there is a little extra bit of cruft... I'll remove that before putting up the final code. This is stuff that just came with Ember App Kit as an example.

I mentioned at the beginning of the previous episode that one of my motivations for starting to use a build tool is so that I could connect with a server API, next week I'll show you how to do that. Until then, happy coding!

Journey to Ember-CLI

Subscribe to our mailing list