I’ve been keeping an Ember Wishlist for a while now, thought now is a good time to post it with the face-to-face core team meeting this weekend. Let me start off by saying I certainly could be misunderstanding a few concepts, so feel free to point them out. I’m going to list each as separate posts (in no particular order) so you can Like and Reply to each. Feel free to post your own! I don’t think these are RFC worthy yet, just thoughts at this point.
Other users suggestions:
8 Likes
Contextual / Traversing Properties
It’d be great if Routes and Controllers would have properties to access their relations (parent/child). This way you wouldn’t need to explicitly needs: [] each possible Route/Controller and then try to figure out which one is active. I was thinking something like:
parentRoute == exactly that, direct parent of the current Route
childRoute == direct active child route of the current Route
childRoutes == array of active Routes traversing the entire tree below it
Same goes for Controllers of course, maybe Views too. If unavailable, undefined would be returned. One question I had, should Routes and Controllers have access to each others relations? Eg: Can a Controller get its parentRoute? Or would you have to this.route.parentRoute instead?
This would be useful when needing to communicate between Route Controllers. My use case is a wizard like process to create a new record where the parent route needs to know the validation state of whatever the current sub route is, to activate/deactivate the “Next” button (which is located in the parent template).
2 Likes
Ember Data option to hold bindings on dirty records
With Embers data bindings, editing records is overly eager triggering bindings. Before actually showing up in lists elsewhere in the app, I first need to validate the data and save it to the database. Seems like this would be a common pattern / use case. Same for changing existing records, wait until successfully .save()ed. Maybe a Mixin or different Class to enable this functionality per Model. And a DS.attr() option to enable per attribute.
2 Likes
Change Actions to Events so .on() Works
This was one thing that threw me while learning Ember. Coming from jQuery, I (and most other developers) are familiar with jQuery’s .on/off() style of handling. I feel like Actions are the same thing. However, this is one thing I feel like I’m missing the concept. I understand that it’s not DOM specific, but why not? It provides natural bubbling as DOM events, up the route tree. Perhaps they could be namespaced to separate from typical DOM events.
Basically what I’m thinking is that actions: { actionName: function(){} } would become foobar: function(){}.on(‘actionName’). This could be combined with matchy’s RFC about better actions by function(){}.on(‘actionName.stateName’)
In this case, should .send() and .sendAction() become .trigger() and .triggerAction()?
2 Likes
Change needs: to Computed Properties
The needs thing is confusing because there isn’t an equivalent for Routes and other aspects in Ember. Remove needs:[] and use a computed property such as fooController: Ember.controller(‘controllerName’), fooRoute: Ember.route(‘routeName’), etc. It also provides the developer to name the property whatever they’d like, rather than using controllers.controllerName. This was part of the Services discussion that Tom Date started.
Services? Yes Please
Ember-CLI already provides an easy way to generate the code needed, but it would be nice if there was just a Ember.Service to extend from. Tom Dale started a discussion on this, and I want! Would be helpful for some Ember-CLI addons too! One thought is the Bootstrap.ModalManager in “bootstrap-for-ember”
3 Likes
Fix Nested Controller Access
I think it’s weird that nested Routes are.like.this but Controllers are/like/this. This became apparent with the nested .route() feature.
Ember News Becoming a First Class Citizen
How about more frequent or at least brief updates/blog posts about current work in Ember and what happened at team meetings. This has fallen by the wayside as of late.
1 Like
Combine Controllers & Views (ala Component)
From what I can tell, all Views really do are handle DOM events and such. Remove one level of complexity. Combine this with the ‘Change Actions to Events so .on() Works’ above and everything could be consolidated on the Controller.
1 Like
Lazy Loading Resources
This has been discussed but just to put it on the list. As apps get bigger, there is more to load at startup. It would be great if parts could be AJAX loaded as needed, to reduce the initial load. I feel like this would be the responsibility of the Container. If something is unavailable, try to AJAX load it using a standard file structure (Ember-CLI Resolver). Convention over configuration, right?
Of course there needs to be a way to define what should or shouldn’t be “pre-compiled” vs AJAX loaded. And probably a way to define where the file should be, overriding the resolver.
Another feature could be pre-loading things; so when I visit page X and it has link-to’s to Y, load everything needed for Y. This would reduce the “wait-time” while routes/controllers are fetched.
More thought is needed on this one. One thing to think through is packaging a mobile app, making sure everything is included in that case.
4 Likes
Route Access from Controller
A Route can this.get(‘controller’) but a Controller cannot this.get(‘route’). If there isn’t a Route to be had, undefined should be returned.
1 Like
Object Observers, No More get/set
With ES6 object properties will be able to be observed directly. This should eliminate the need to .get() / .set() properties.?. This is one thing that AngularJS toutes and something Ember could eliminate.
9 Likes
Enhance Native Object Instead of Ember.Object
Not sure if this is possible but one of the things AngularJS toutes is the ability to work with POJO’s. Is it possible to prototype the Ember.Object functionality so that Ember can use POJO’s? This is in addition of removing the getters and setters mentioned in “Object Observers, No More get/set”.
2 Likes
Ember Data LocalStorageStore
To reduce the browser memory footprint needed by Ember Data apps. This isn’t a LocalStorageAdapter, but actually using LocalStorage to keep records returned from an Adapter. So the records aren’t in memory but rather LocalStorage. Just a thought to improve the overall footprint of an Ember app.
6 Likes
Ember Data Built-in Support for “Offline Mode”
Need I say more? Perhaps a can-of-worms deal? This could tie into the previous wish, “Ember Data LocalStorageStore”. How is OrbitJS looking BTW?
4 Likes
HTML Custom Elements == JavaScript/Ember Component
Instead of {{my-component}} use <my-component>. I think this is coming with HTMLBars.
Use <template> for Templates
Now that I’m using Ember-CLI, this has become a non-issue. However, I’d still like to see global Ember apps use <template> instead of <script> tags to define/contain a handlebars template. Perhaps there is more to this one though…
More Built-in Functionality!
Ember could be even more opinionated! There are things still missing from Ember that are common patterns. Too much “that’s better as an addon”! Possibilities (please add more);
- Form validations
- User roles
- Authenticated / Authorization routes
- Session management (current user info)
- Buffered proxy/changes
5 Likes
Better Input Helpers
Ember Select, need I say more? How about a radio option? Should these be components instead of helpers? Again, sounds like these will be improved with HTMLBars.
2 Likes
Route Model Dependencies
This came up in a Discussion, a solution is needed for Route model dependencies when a {{link-to}} passes in an object instead of model id. This does not fire the model hook and therefore doesn’t load the related hashed dependencies.