What are right uses of controller

Just a note, if you are using top level controllers (controllers created alongside routes) it’s not really neccessary yet to replace them with components, as the docs mention a softer transition will be available for those controllers when routable components will launch:

“However, existing applications that make use of top-level Controllers do not need to immediately eliminate those controllers. As with top-level views, the future Routable Components will provide a softer transition for this use-case and we commit to support the compatibility addon until the community has had a chance to transition to Routable Components.”

Thanks. Its new application and so no controllers yet. I will take that in mind!

Here’s some of my writing on the subject of routable controllers and routable components: Controllers are dead; Long live Controllers

1 Like

It’s not likely we’ll see routable components anytime soon, they’re not a priority. Likely at least another year before they ship. We should get comfortable with controllers.

Who said they’re not a priority? There’s a lot of work to be done/being done in preparation for routable components.

Routable components were promised over a year ago. They were originally suppose to land in 1.12. They were delayed at or shortly after emberconf until 1.13 final. Then they were delayed shipping until 2.x (“extremely likely to land in 2.1, or 2.2 at the latest.”). Then after that they were delayed until after angle-brackets and pods work were completed.

Since then, features like glimmer, angle brackets, rewrite pods, fastboot, engines, etc, etc, have all been worked on instead. No work has been done on routeable components.

What evidence do you have that routeable components ARE a priority and will even ship in 2.x?

You need glimmer components (angle bracket components) and pods to have routable components. You need glimmer to have glimmer components. That’s what I meant by there’s a lot of work being done in preparation to routable components. There is also Ember CLI things being done that are related to this, new resolver, addonification of Ember and Ember Data.

I’m also very much looking forward to them, but software is messy and sometimes things take more time than initially thought, and you have to shave a lot of yaks along the way :\ That’s partly why core is trying not to set specific release versions anymore. You can mostly track progress through RFCs, PRs, and the feature flags in Ember.

Yea I know that’s what you meant. I’ve heard that explanation before. Pods, Angle Brackets and Routeable Components are all circular references. Ember should have landed Routeable Components first to make good on their promise, then landed the later two features.

Exactly. When you are managing a framework and big/complex apps are using your framework they count on predictability. Many companies have to manage their own timelines and expectations. Balancing feature work and tech debt. This is not what we’ve gotten from Ember in the past 18 months.

Another related note is not having routeable components is causing a lot of pain for new users. Just check this form. Many new people read blog posts about how routeable components are the 2.x way and how controllers are bad. They want to be good citizens and follow these guidelines, but can’t and get confused. Routable components would solve way more problems for users than pods or angle brackets.

1 Like

Pods and angle brackets are a pre-requirement for routable components.

Routeable Components could have functioned without pods or angle-brackets in the same way current view/controllers do. “Do pods and angle-brackets make Routable Components better?” – Of course they do. But they did not have to be pre-requirements. Ember core just wanted them more than they wanted Routeable Components.

Sorry for hijacking your thread @mtangoo, I’ll stop.

@RGL9032 feel free to contact me on IRC or Slack so we can discuss this more properly.

No, you didnt. Its very informative actually. Keep it rolling please :wink:

@locks thanks for the replies here about routable components.

I can totally understand the frustration people feel about perceived delay of routable components. I think the problem for many people (myself included) is that the messaging around controllers is fairly muddled. Perhaps the mistake was talking about routable components far too in advance (the road to ember 2.0 blog RFC).

Perhaps the core team should release some clarifying blog post that addresses this and rolls up some of the points you outlined here. And own up to some of the messaging problems.

As an aside, how do you bubble an action from a controller up to a route and when is proper to do so?

I have lots of places in my code where I have an action, need to do a little work and then transition to another route. But my dilemma is as follows:

  1. Can’t use “transitionToRoute” method in component action (no easy access to router)

  2. Normal controllers don’t feel like proper place to do this. (And I am trying to eliminate controllers from my code base anyway)

  3. Using sendAction inside controller’s action just to forward along behavior seems verbose and problematic.

  4. The nuanced use cases around closure actions are still poorly documented or obscure. (Need more clarifying examples in guides)

There are few people more frustrated than me :stuck_out_tongue:

That’s up to you to decide. I’m guessing it would be the same as deciding whether an action goes on a route or a controller, being dependant on your application structure and problem domain, and personal preference sometimes. I don’t think this is something that can be easily prescribed.

They know. Not that I think it’s a good idea to transition from inside components, but that’s a conversation for another time!

As I state in my blog post, I think getting rid of controllers is a misguided venture.

You can instead use ember-route-action-helper to close over route actions instead.

It’s send (only components have sendAction) but I get your point. This is still better than having to cascade explicitely through each layer of components.

I can’t do anything with this feedback to improve on the current guides. I suggest opening issues with specific problems you have come across that you’d like to see explained in the guides.

@locks which is YOUR suggested way in these two cases:

  1. Handling Login for example with simple-auth? Will you use Controller as they suggest in their github readme?
  2. User submitted data to create/update blog post for example. Will you use controller in that case?

I’m interested to hear your opinion on that! Thanks

If they suggest it in the README there’s probably a reason :wink:

Not quite sure what you mean. Are you talking about binding form inputs to controller properties? That’s a bit context-dependent, but there might be a more suitable alternative so you don’t have to worry about resetting controller properties when navigating out.

@locks That’s what I mean. If I have a blog post and I hit edit I should be able to change and save that specific post. Now in light of “controllers” should be avoided when possible, how do I do that?

for reference this link explains very well on component sendAction and is eye opener http://coryforsyth.com/2014/09/24/communicating-with-ember-js-components-using-sendaction/

@mtangoo Yes, this is quite frustrating.

I can’t wait for Routeable Components, and I agree with @RGL9032 above – dependencies seem like nice to haves but seriously I don’t get why pods and angle-bracket are needed. I tried the routeable components experimental feature flag, and it worked just fine.

I have nothing against controllers except they are cognitive burden. When learning a framework, I’d rather have to learn 5 concepts than 6. That’s a bad tradeoff for something we could dispose off and no one would notice much.

Should we use controllers in Ember 2.0? That is what I asked myself a few months ago:

http://emberigniter.com/should-we-use-controllers-ember-2.0/

1 Like

Your post clears a lot of mist @emberigniter

1 Like