What are right uses of controller


#1

I have been reading the guide and it seems like its good to put almost everything in components. As it’s written there, someday a controller will be gone. So I wanted to know what’s is the right use of controller that will easy moving towards component only system once its done in Emberjs and controller become deprecated?

The only use I know now is setting various variables used by view and component


#2

If you want to ease the future transition towards routeable components, your best bet is to not use controllers at all (there will be one, auto-generated by ember, with nothing in it). Then use a simple stub template that instantiates your component.

{{! templates/some-route.hbs }}
{{some-route model=model}}

Only catch is this will break action bubbling. To prevent that, you must explicitly name the actions that you component will send to the route, for instance:

{{some-route model=model save='saveMyModel'}}

That way, calling sendAction('save') inside your some-route component will invoke the saveMyModel action on your route, with proper bubbling.


#3

Thank you. I have not comprehended everything yet but I get your main point!


#4

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.”


#5

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


#6

Here’s some of my writing on the subject of routable controllers and routable components: http://locks.svbtle.com/controllers-are-dead-long-life-controllers


#7

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.


#8

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


#9

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?


When will routable components land?
#10

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.


#11

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.


#12

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


#13

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.


#14

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.


#15

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


#16

@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)


#17

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.


#18

@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


#19

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.


#20

@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?