We are currently on v1.6.1 and since components seem to have replaced views we thought about converting our controls to components before upgrading since we have a massive code base.
However, we’ve been running into issues especially w.r.t. sub-classing components and rendering components types using:
{{view ComponentType}}
So my question is whether it is worthwhile trying to create these components or should we rather just upgrade to the latest version and refactor in one go?
Upgrade in a step rather that trying to jump straight to stable or convert you’re entire app in one go. For example, get to 1.7.0 and remove deprecation warnings and convert a few components. More on to 1.8.0 and repeat. Keep doing this until you’re on stable. This approach I found to result in a lesser chance of your “upgrade” branch from going stale and forever being married to 1.6.
Just my opinion of what works best. I’ve upgraded a fairly large app, ~70k lines, between Ember releases and from globals to ember-cli. All while 20+ engineers working concurrently on the codebase.
From v1.8 there is no more access to singleton views so that means we should have everything converted to components.
Is the v1.7 component implementation stable/complete enough to handle proper composition? I noticed that the ‘component’ helper is only available in v1.11+.
We have ~300 people on the project at any one time. Over 20 scrum teams each with 2-3 developers. Our team is responsible for the Ember-based framework (comms + controls) and we will shortly be handling over to our continuity folks (also ~300) and our team will be the framework team for both bits (so ~600 folks). We have 323 handlebars files that will have to be changed and we will need a full regression each time. Changes to the framework are loathed by the other teams as they also need to re-learn the stuff.
I guess doing it little by little is first-prize and we had hoped to develop the components and then swap out all our controls. After that we’d upgrade to the latest version and take a big knock. We should have time after June 2016 given our go-live requirements.
So timing is also an issue.
As I mentioned, we are running into issues with the components and I do not know how much assistance we are going to get for v1.6.1 and all versions in between.
Our development manager has asked us to look into other frameworks (even paid) but I reckon we’ll have the same issues none-the-less.
I’m not sure what a singleton view is. Views are not singletons by nature, neither are components.
If you can get away with chained if helpers. If not, then you’ll need the component helper.
This is something you need to work out with your development manager. I don’t know of a framework worth considering that isn’t evolving with the web.
I’m not sure what a singleton view is. Views are not singletons by nature, neither are components.
Apologies. Incorrect wording. What is deprecated is the “global lookup of views”.
If you can get away with chained if helpers. If not, then you’ll need the component helper.
Chained if will probably not work for us as the composed component contains some logic that we will not be able to specify as attributes.
This is something you need to work out with your development manager. I don’t know of a framework worth considering that isn’t evolving with the web.
Agreed. Breaking changes, however, do have a massive impact on us 
Mostly everything that is deprecated is in some way support in 2.0 through adding. And I don’t know of any breaking changes in 1.x as they do their best to follow semver. Depreciations warnings are just that… " warnings of future removal or breaking API changes.
Global lookup of views should work all through 1.x and it’s more of a mechanical change that’s solved through a regex find/replace.
Also checkout ember Watson. Helps with migrations.
Mechanical change or not it is still a change and that is a problem.
I’m afraid that I’m not convinced that it is that simple. I have been dealing with Ember since pre2 so we’ve experienced a lot of pain along the way. We even wrote our own converter to get to version 1.
Anyway, thanks for your input. For now I am going to advise that we upgrade in a single step after June 2016.