Officially controllers are deprecated in favour of routable components. However, using routable components is not possible because it is not implemented in an official release yet. This means we are left with using the deprecated model of controllers, and all documentation is how to use controllers, and all tutorials available utilize controllers. The releases made every 6 weeks don’t mention any progress on the feature, and nowhere (at least what I’ve can seen) is there a roadmap of “when can we expect to be able to use this”. Is it Ember 2.4, 2.5, 2.8 or even 3.0?
I’m currently building a pretty major application using Ember and feel kinda dirty because I’m using controllers. Also because I’ve currently run into some issues because of the fact that controllers are singletons, I’m trying to move away from them. This leaves me with the question of “with what?”. Searching there is no real documentation on what I should be doing, and no idea of when I can expect.
I realise it’s currently in development and it’s hard to put a time on releases in software, but how about just a scale? Short status update? Is it weeks months or years? It’s also a bit frustrating because all up-to-date documentation mentions routable components as the way forward.
I too am very frustrated by the absence of Routable Components. I had a small rant about it here: What are right uses of controller
The TL;DR; is that Routable Components will not be worked on until “Enhanced Pods” (or Pods v2) and Angle Brackets (Glimmer Components) have both been completed. Angle brackets is not likely to appear until 2.5. Assuming enhanced pods isn’t worked on in parallel, that put’s it’s earliest at 2.7 or 2.8. Only after both of those things have been completed, will Routable Components be worked on, so likely 2.11 or 2.12.
So if you assume that Routable Components is 9 releases and each release is 6 weeks apart, that puts it about 54 weeks out. Who knows what will really happen.
This makes me really sad and frustrated. It causes a lot of confusion for new users and it results in a lot of undesirable controller code or weird “fake routable components” for those of use trying to practice the proper patterns.
Ember.Controller is not officially deprecated, as features can only be deprecated when the alternative is already in the stable version. The 2.3 release blog post mentions that 2.4 will feature solely performance improvements, so it won’t be before 2.5 at any rate.
There’s nothing wrong with controllers themselves. See @RGL9032’s link for a discussion on the subject and particularly my blog post.
It causes a lot of confusion for new users and it results in a lot of undesirable controller code or weird “fake routable components” for those of use trying to practice the proper patterns.
Here’s how we handle it at The Frontside: if it went into a controller before it still goes there now. That is its proper living space right now. It would probably make it harder to migrate if you start devising your own solutions. I’m sure the core team will have a very sane way to transition from your controllers to routable components.
So that’s one of my biggest frustrations is it’s not suppose to be at this point. There were several points where it was said, “Routable Components are coming the the next release”, “Routable Components are around the corner.” We were encouraged to adopt these patterns. As an early adopter, I know getting burned is the risk you run. But usually it’s because the APIs changed, not the priorities.
My second frustration is there really is no status update or acknowledgement that Routable Components is MIA. None of the blog posts since 2.x have mentioned what the status of this project is. We’re all just hanging out in limbo, trying to read between the lines in slack messages or RFC comments.
You state that a status update is needed, but you very clearly listed in When will routable components land? - #2 by RGL9032 the list of blocking features. It seems to me that the status is well known.
Neither of the quoted messages indicate that you should do anything but look out for something that is coming later. How can adoption be suggested of something that doesn’t exist? This doesn’t make sense.
If the singleton nature of the controller is impacting you (this generally isn’t an issue, but it definitely can be), you can change your route’s template to invoke a component in its root. This way you tie your state to the component which has a lifespan that is more in tune with what you need.
Thanks for the reply, the suggested solution is probably the route I’ll go down. That’s also the reason I was looking into routable components, because it seemed to be exactly what I’m doing.
That pods and angle components are being prioritized is completely new to me. I’m also greatly looking forward to those features. My confusion probably arises in that I only follow the development from the official blogs, the official documentation, and sometimes venture into these forums and read RFC’s when I come across one. I really hope I’m not coming across as whiny or demanding but: I think at least a blog post about what the current status looks like would really help a lot. Where is everything now, what is the current plan for the future, and really really really rough guesstimates.
(And I believe a lot of the frustration simply comes from that everybody is so much looking forward to the new awesome features, and the great stuff everybody is doing!)
The status is well known to me. I actively followed dozen of feeds to stay as informed as I can. But there is still confusion amongst many users. This post is just one of many where users are trying to use Ember and stumbling over the concept of routable components or “how to not use controllers”.
Ember could really use an “official update” on the blog about the status of Angle Brackets, Enhanced Pods, Routable Components and what to expect over the next year. I know that you guys have been burned in the past by saying too much, making too many promises and creating unreasonable expectations, but right now nothing being said. It’s not at all clear what’s going on behind the scenes. This is from the latest blog post:
No new features are slated for Ember 2.4. During the canary cycle leading to this beta, the core team and community have been primarily focused on performance improvements or feature work still behind a feature flag.
Many of use want to know what the work is behind feature flags. Not knowing what to expect is kind of tough when you’re maintaining a product you’re trying to keep up to date. A little information can go a long way.
EDIT: One other thing that would go along way is if there were notes for the core team meetings again. This repo hasn’t been updated since November:
So, when will routable components land?
Where can we track the status of main upcoming features and their dependencies, etc? I can’t find anything.
My understanding is they are still blocked by the Glimmer 2 work which is still on canary. Our goal (learning team) is to long-term build a features dashboard where this type of stuff will be more visible. It’s been a desire of the core team for over a year, just haven’t had enough helping hands pushing
Thanks @acorncom! While building a features dashboard sounds fantastic, how about a plain text document for starters? I can help but have no idea of what’s going on since everything seems buried deep down in github rfcs or issues – that’s why I was asking. Where do we start?
I am very happy about Glimmer 2, it’s making Ember a wonderful framework. The thing though, is I don’t think Ember beginners (and many other devs for that matter) deeply care much about Glimmer 2. They just want their app to render fast. They don’t really care about partials or components – they just want to know their app is architecturally sound. Think “benefits over features”.
My goal is to bring this core-team-speak down to Earth. What features are being worked on and how will that make my Ember developer life easier? Which tradeoffs can I make, risks should I take, by being aware of possible directions of the framework?
Right now, it seems all this information is buried somewhere. I could be COMPLETELY wrong, so please feel free to point me to the right place.
Otherwise where can we talk? I’m not a big fan of Slack but if that’s the place… let me know.
Nope, don’t think you’re wrong The closest I know of is https://github.com/emberjs/ember.js/blob/master/FEATURES.md which (like you mentioned) isn’t exactly normal-dev friendly. The PR I opened at https://github.com/emberjs/website/pull/2393 was an initial first stab at getting this going. We closed the PR for now because it’s on our radar, but we don’t have time to get it going just yet.
So yes, I’m fully on-board with your thoughts and would love to see what you are describing built. It’d probably be simplest to discuss on Slack (any reason you’re not a big fan of it?) on the
#-learning channel. Ping me when you’re around (I’ll be more free tomorrow / Friday MST) and we can fire up a video chat.
There’s another guy who has also expressed an interest in helping that project move along, so we might be able to have the two of you collaborate on it with me asking questions / poking people as we need.
Oh man this would be fantastic.
I’m happy to help too!
This is a real pain point for me with Ember and I would love to contribute.
@averydev not sure if you’re discussing helping with the feature system or something else. If the feature board, look me up on Slack and I can put you to work
@acorncom Yes, I’d love to help out on the feature board! I’ll find you on Slack…
YES, a feature dashboard would be so, so nice. I’d offer help.
I’ve created an addon that enables routable components for Ember 2.7 and greater. You can find it here: https://github.com/mdehoog/ember-routable-components-shim
@mdehoog thanks for that! Can I just ask whether you would recommend using that shim in a fairly small production app?
@aexmachina I’m using it in a production application. Any changes to the
outlet keyword in Ember may break the addon, but I will attempt to keep it up to date until routable components are officially supported.
Looks good! How does it work with query params?