Diving Deeper Into Ember

[chrisblackwell]

I have been working with Ember 2.0 recently, and I keep hitting the wall. Whenever I try to do something, I search for the way to do it, and constantly get ways that are deprecated or will no longer work at all.

This keep frustrating me, as I’m really interested in deepening my Ember knowledge, but I spent a lot of time trying to do the simpliest of things.

Specifically, I know that Controllers are going away, and Components are taking over. However, whenever I Google how to do something (like pass a success message on create), I keep finding articles on using Controllers.

Is there any resource, book, videos, whatever, that you can point me too? I’d love to hear others experience, and hear when people had those “ah ha moments”.

[broerse]

I hope you can get an ah ha moment from my attempt to explain the current state we are in:

Creating/Using EmberJS component

So let me try to explain the deleteAction and the authors on the controller. We are in the middle of switching to routable components. Therefore we still need to pass data like authors from the route to a controller. You do this with setupController. The default for Ember is content. If you need more models like authors you can use Ember.RSVP.hash to get them and wait for all promises to resolve. See: Now we can move authors to the post controller. https://github.com/broerse/ember-cli-blog/b…

[emberigniter]

Hey Chris, I think in this case your best bet is to understand how controllers and components compare (despite knowing that controllers will go away rather soon).

Components have three functions in old-Ember parlance: controller (in that it keeps some state “backing” a template), view (where you’d interact with the DOM) and the template.

So that is: component.js = controller.js + view.js & component.hbs = controller-backed-template.hbs.

(It’s possible to minimize the use of controllers, using these only to receive a model from a route and pass it along to a component.)

Controllers had another use, maybe you came across the needs API. They were used not only to hold state from their templates, but to hold other long-lived state, possibly of other parts of the application. This is what Services do now.

Please ask me any questions you have if you don’t understand. If you are able to “translate” between the old and the new Ember worlds, you will be able to understand outdated articles (at least get something out of them) yet apply them to your new project.

[varblob]

Controllers are going away but the replacement isn’t done yet. You may find it useful to read the routable components RFC to see how it will be replaced. This article is a little old but is still one of the better ones out there for how to bridge the gap to 2.0.

[workmanw]

I’m a pretty visual person and I like graphs and charts to help orient myself. Recently I was explaining this transition to other members of my team and I built a few graphs to help. I’m not sure if this will help or not, but hopefully it won’t hurt.

---

Ember 1.x:

---

Ember 2.x:

Ember 2.x w/ shared service state:

---

Currently Ember 2.x Shimming (during the transition):

Until routable components are complete, this pattern is what you’re left with. You still need the controller and the view (though you may not need a view class, a template is a view in this example). The view/controller act as “glue” that will go away once routable components exist.

[rwjblue]

@workmanw

I’m a pretty visual person and I like graphs and charts to help orient myself. Recently I was explaining this transition to other members of my team and I built a few graphs to help. I’m not sure if this will help or not, but hopefully it won’t hurt.

It is quite helpful, thank you for sharing!

@workmanw

You still need the controller and the view (though you may not need a view class, a template is a view in this example). The view/controller act as “glue” that will go away once routable components exist.

In general you only need controllers for two things:

1. Use with query params (there is a feature on canary that can be enabled to move this to the route, but it isn’t enabled by default and still needs a bit of work to get to a “default on” state).
2. Bubble actions to the route for closure style actions. Using closure actions today is not required, but using them is a good start to moving forward into the non-shim version of the graph.

[workmanw]

@rwjblue

Controllers also provide the only mechanism to obtain ancestor models for “routable components”, even if it’s kind of indirect. If I’m practicing the 2.x routable component pattern and I need to share multiple values from my route to my “routable component” (which is super common for us) I have to use a controller. Eg.

---

// app/routes/blog-post.js
export default Ember.Route.extend({
  setupController(controller, model) {
    controller.set('blogPost', model);
    controller.set('project', this.modelFor('project'));
  },
  /* ... */
});

---

{{!-- app/templates/blog-post.hbs --}}
{{routable-blog-post project=project blogPost=blogPost}}

---

This use to be done with needs or Ember.inject.controller, but that is no longer possible with this pattern.

[rwjblue]

@workmanw

This use to be done with needs or Ember.inject.controller, but that is no longer possible with this pattern.

You are definitely correct, but this isn’t a pattern I find myself using a lot. I have generally preferred the setupController approach. Though I do it slightly differently (and in my normal usage setupController itself is provided by a mixin):

import Ember from 'ember';
const { hash } = Ember.RSVP;

// ...snip...

model() {
   return hash({
    model: this.store.find('post', 1),
    project: this.modelFor('project')
  });
},

// this is provided by a common mixin
setupController(controller, hash) {
  controller.setProperties(hash);
}

[workmanw]

@rwjblue That’s interesting. Though the only downside is that if someone else were to do this.modelFor('blogPost') they’d get the hash (with project and blogPost), instead of just the blogPost.

But I’ve digressed now. The point of that last slide (with controller) was just to show that’s the current “glue mechanism” for sending data down to a “routable component”, even if it’s entirely autogenerated and automated, is a controller. It’s still part of the “shim layer”.

[dennismende]

Rock n Roll with EmberJS of Balint Erdi was updated a few days ago for Ember 2.0.

The most up-to-date book to learn Ember Octane

[niconel]

Rock n Roll with EmberJs totally worth the money. The author update the book like every week or two (at no extra cost)