Ember Wishlist!

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.

I would like to see better inspection and debugging tools. The inspector works great, but it comes short when understanding the actual flow of execution as well as inspecting ember objects. Of course, I can use console.log but it just shows an object with a deeply-nested, complicated and difficult to understand structure. Not sure if it’d be better to expand the functionality of the inspector which may make it too complicated or offering a (javascript) toolset which would help out.

@kgish Have you tried the debugger to set breakpoints in your code? There is also a {{debugger}} Handlebars helper. http://emberjs.com/guides/templates/development-helpers/

Here is a guide on debugging: http://emberjs.com/guides/understanding-ember/debugging/

And finally a logging service: Ember - 4.6 - Ember API Documentation

I feel like the debugger is what you’re looking for. Or can you elaborate?

Yes I am aware of these links and find them very helpful indeed. Perhaps a good tutorial showing a couple of hands-on debugging case studies would elaborate things better. I am often very confused when setting a breakpoint where in the general flow I am and where to look in order to trouble-shoot problems.

All the suggestions above in this article seem awesome. Thanks @Panman8201 for taking the time to write them up.

Really hope they’ll be implemented at least some of these one day :smile:

1 Like

Moving the CC’ed people here since I plan on updating the first post when new suggestions come in and I’m not sure if that triggers another notification for them.

CC @rwjblue @trek @stefan I’ve worked with you guys before, would love to hear what you think. I know you’ll be hard critics but I’m open to criticism.

What do you want Ember.Service to have?

Seems like your wish is coming true in Ember 2.0! :stuck_out_tongue:

Especially the session management and form validation could use some built in solution.