Upgrading from Ember v.1 to Ember v.2


#1

Hello,

I’ve got a fully working app built using Ember version 1.8.1 and now I’m looking to transition to using Ember version 2.2.0 along with Ember CLI. However, I finding it really difficult to get my app to work with 2.2.0. It just seems like a lot has changed. Furthermore, I’m not sure I’ve got my head around the concept of components. As an example, previously I was able to access controller objects within my view. However, people seem to suggest that Ember.View.extend is deprecated? and that I should use Ember.Component.extend? Having took the advice and done so, I find that I’m struggling with the basics like accessing controller objects in components.

Am I being stupid here? is it worth upgrading my app to use the new Ember? Has anyone else found it difficult transitioning from Ember 1 to Ember 2?


#2

Hello,

We upgraded our app from Ember 1.10 to Ember 2.1 in one shot. It took quite some time, it was very tedious and very time consuming, but we did it and are very happy. I just want to speak to our experience with our app. Others can weigh in and possibly have contradicting experiences.

The first question is are you on ember-cli or some other ES6 based buildtool? If you’re not, you should do this first. Converting from a “globals app” (eg. App.UsersController = Ember.Controller.extend()) to one that relies ES6 path based lookups is the first and most frustrating step.

I’ll follow up with more details about our upgrade experience once I know if you’re on Ember-CLI or not. I just didn’t want to type out paragraphs of info that were unnecessary.


#3

Hello Workmanw,

Previously I used Ember Brunch as my build tool which uses the global “App” convention. I’ve had a play with Ember CLI and have noticed that using the ES6 modules means that connecting everything up now relies on importing and exporting files? What’s the best approach in transitioning to Ember CLI? For example if I was to stay on Ember 1.8.0, would it be relatively easy to just change the build tool as a first step?


#4

Hey @dchan38098,

Okay yeap, that’s what I figured. So the first thing to do is like you said, transition to ember-cli with your 1.8 app.

Here’s how I would approach it. Start a new app from scratch (ember init). Once it’s built, go into your package.json and bower.json files and update them accordingly to match the dependences of your existing app. Then rerun npm install and bower install.

A few notes about this, some of the packages in the package.json will relate to ember at runtime (ie ember-data) and some of the packages will relate to ember at buildtime (ie ember-cli-htmlbars). I was looking through the CHANGELOG.md and it seems ember-cli version 0.1.3 was the version that “by default” supported Ember 1.8.1. So even though that version is quite old, you might want to start with that as your npm global version.

Honestly I don’t know if that will cause more headaches or save you some headaches, but it’s what I would try. Reason being is if you use Ember-CLI 1.13.13 right out of the box, it’ll come with addons like HTMLBars and others that might not be compatible with your old version, it’s really hard to say.

Maybe one of the Ember-CLI experts can weigh in on this.


At either rate, once you’ve got the shell of your new ember cli app up and running, it’s time to start bringing in your existing files. This can be kind of tricky. Here is the best way to approach this. Create a folder called “legacy-app” in your “app/” directory. Copy ALL of the files from your app, into that direction

Next create an initializer called “global-imports” (see initializers). In that file you should import every single one of the files in your legacy-app in the proper order. This will ensure that all of your existing global classes end up globally accessible. This is temporary until you’ve migrated fully to ember-cli.

Then you will create “stubbed” files in the proper ES6 directories that match all of the files in your legacy directory. For example:

// app/controllers/user.js
import Ember from 'ember';

export window.App.UserController;

The idea here is that you’ll shim in ES6 path based files around your old app. Once your app is all functioning with this approach, you’ll begin to refactor one controller/view/route at a time. Moving them from the “legacy-app” directory into the proper ES6 location and removing all global usages that exist (eg App.helperFunc()).

Lastly, you can probably just put your CSS/SASS/LESS files in “app/styles” directory and your Handlebars files into the “app/templates” directory with little effort. The templates should just work, you may have to move them around into the proper subdirectories to get them to lookup right. But this shouldn’t take much effort.

This whole thing will take time and there will be unforeseeable hiccups. But I have heard success stories of people using this approach.

**Disclaimer: I don’t know if this is the official upgrade strategy. I don’t know if there is even an official way to do it. Quite frankly ember really falls flat at helping people who get behind. Others may have thoughts on how properly convert from globals to es6 path based.

Edit: This is all what I would call “Stage 1” of your upgrade. It’s important to fully convert to an ember-cli app before attempting to upgrade ember.


#5

Thank you very much for your time in writing this. I will definitely give it a try and see where I get. From your experience would you say it’s highly beneficial to upgrade to 2.2.0? Did it change the architecture of your app in any way?


#6

You’re welcome. We went through the upgrade cycle and it was kind of brutal for us. I wish that I could better help you avoid some of those headaches. It’s hard not knowing much about your app.

Yes. 100% Yes. There are two streams of improvements we got.

The first, and most significant to me, was an improved architecture which is exactly what you’re asking about. On some level Views/Controllers will just become Component/Services. And you’ll think it’s not really that different, and to some degree that ends up being true. But I think that after a while I started to appreciate the fact that Components are “rethought views” (or views v2) and services are “rethought controllers”. The things that felt weird about the former were resolved in the later. One great example is the {{action}} will target the component by default, rather than some random controller like views did.

The second stream was new features. Going from Ember 1.10 to Ember 2.1 there are two features in particular that I really loved and get a lot of value from, closure actions and injected properties.

It’s also worth mentioning that many people have claimed a vast performance improvement going up to 2.1. We work pretty hard to fend of performance issues as it is, so we didn’t really get a “magical improvement”. But enough people seem to have.

All that said, I work for a very small startup with a complex app. It’s often hard for us to justify and prove ROI on these investments. It can be hard to quantify in terms of measurable business improvement. But as a developer, we see an improvement in our code patterns and to some small degree a reduction in the amount of code we had.

If this is something you’re on the fence about and maybe want to talk through more, I’d be happy to jump on a hangout and we can talk face to face about it, or I can show you some of our code and we can exchange ember war stories.


#7

I upgraded a fairly large/complex app from 1.8 to 1.13, then 2.x… at the same time as converting from a globals app to ember-cli.

I took a different approach. I started a fresh app with ember-cli and ember v1.13.x and ported the business logic over piece by piece.

I specifically wanted to have a different architecture - more based on components… so I set about building the base/guts of the app from scratch. Once I had the bare bones skeleton (all the generic app stuff) built with components I set about copying/pasting the buisness logic from parts of the old app to the new app.

Basically… I took it as an opportunity to re-build my app from scratch… because I thought it would benefit… and it did.

Once you get into the v2.x way of things, its much better… better performance, and easier to debug.


#8

Interesting. This is definitely the exact opposite of what I did. I felt that going step by step would result in less regressions and give me more time to ease into it. Your approach is more like a clean break. Ultimately it’s probably 6 in one, half dozen in another.

One question I do have is how long did it take you to even get your app to load? It seems like there would be so many interconnected dependencies and you’d end up bringing over 10% of your app before you could get anything booted.


#9

It was a while back now… (when 1.13 was the latest version)… I wanted a clean break - The old app relied so much on views and other stuff that was being deprecated…

I spent a while building the app up from scratch… building some fundamental components that formed the basic structure of my app - all the generic stuff like tabs… menu structure… login/out/users/profiles/modals etc… This took me a while, but no different to starting any app from scratch i guess.

I was learning the v2 (components) way of things at the same time as learning how to use ember-cli… so I wanted to start from a blank canvas and just focus on getting the foundations of the app in place.

As i started to copy over parts of the original app, I did it bit by bit as I wanted to refactor some of the code at the same time as removing deprecations, etc. I did have to copy over a fair chunk of code to get things going and there were a lot of loose ends for a while… but the app is fairly modular and I could work on parts of the app fairly easily without other parts of the app in place… There was never a time when the app wouldn’t boot… but it was a long time before the app was complete with all the original functionality.

The app didn’t change from the user’s point of view… the UI was the same… and the functionality of the app was the same… but under the hood I had changed things a lot and performance was better.


#10

Hello workmanw,

Thank you very much for your help. I have progressed since and now I’m confused about adding dependencies such as moment js. I’ve installed it via bower and included in the brocfile. However, it seems like it’s out of scope when I try to access it in a controller file or view file. Do you have any insight on why this is happening?

P.s. I would definitely like to learn more and even see some of your code. With Ember there is always question of whether you are doing things correctly even though they work and really the only way to know is if you see how other people do it. The only problem is the ember app I’m working on is company property, hence I would probably get the sack if I showed you any of that hahaha.


#11

Thank you Loz Jackson. Originally I was going to take this approach too but I ended up doing it the way Workmanw suggested. :slightly_smiling:


#12

brocfile changed its name to ember-cli-build since version 1.13 IIRC. Maybe that’s your problem.


#13

Hey guys I am transitioning an old ember app from 1.7 to 1.13 and eventually 2.x There is a todo form which have 3 js files and 1 hbs todo_view.js, todo_controller.js, todo_form.js – each of them importing couple of more dependencies I need to convert it into a component Any idea how to architecture it as component can have 1js and 1hbs