Emberjs routing

[stas]

Hey guys,
I took some time during last days and updated a bit the ember.js + require.js app.

A lot of things changed, where most important is probably the fact that the whole app now works without any calls to the globally exposed namespace, which should simplify and improve tests (which still require my attention) a lot.

I still have some questions (hopefully somebody from Ember.js team will find some time to answer those), like:

• currently the entriesController doesn't reflect very well the ember idiom, it would be nice if I could get some hints regarding how it can be improved (probably, just rewrite the whole localStorage model). Also because of this, connectOutlets calls might look also unfamiliar, any suggestions are welcome
• all the elements that change dynamically in the app were moved to ContainerViews, some of the view templates like app/templates/stats.html require scope to be specified, not sure if that's a bug or a feature, looks weird
• should I update the app with each helper instead of CollectionView? Whats the best practice?

Tests to be updated soon.
Thanks.

[addyosmani]

cc @tomdale

[addyosmani]

I should mention that we also have a non RequireJS ember app that I've been working on in branch. Might be useful to keep some of this parallel work in sync so that people can easily compare the differences between them.

Pardon the stupid question: is the routing in this app the native ember routing Tom and c/o were talking about a month ago? If so, it would be great to also get that into the non-RequireJS app.

Will wait to see how this thread progresses in case there are learning we can share across the two apps.

[stas]

Yep, I'm aware of the current state of the non-require.js app. I will take a look and update it too to include routing support once we get the feedback for this PR.

Regarding routing, yep, current implementation is natively offered by Ember. Tbh, current version I'm using is the unreleased ember-latest.js

[addyosmani]

Although we usually aim to use the latest stable version of projects, I'm really keen to have proper ember routing landing for TodoMVC 1.0. @stas this looks good for a merge. I'm going to double check to see if theres anything more to be done on the ember app after this so we can land that (and if anything is still waiting on the RequireJS one, land that too).

Thanks!

[addyosmani]

Hey @stas. I was wondering if you might be able to help with something related to the routing of the default/standard Ember app I'm working on in branch:

We have this concept of Todo model filters (default, active, completed) where
if a user navigates to any one of these via routing, the option gets class="selected" added to it in the footer,
or at least, is supposed to.

https://github.com/addyosmani/todomvc/blob/emberjs/architecture-examples/emberjs/index.html#L37

Routes: https://github.com/addyosmani/todomvc/blob/emberjs/architecture-examples/emberjs/js/router.js

In many other apps what we've been doing is simply triggering a call to a function that accesses the DOM
and adds the selected class to the correct link within the routing, but for Ember I noticed that most people
don't explicitly wait to execute components on DOM ready (at least not outside of what the framework itself does)
meaning that this doesn't actually work.

I figured that perhaps I was thinking of the problem incorrectly and instead that I should simply be perhaps checking
against showAll, showActive or the current route within the template in my index.html. I would then add the selected class within a footer link if it was the correct one was detected (e.g if the route === 'active'). This hasn't been working out so
well either, so I'm wondering if I've missed out on something extremely straight forward.

Still getting used to the routing/state management changes so I really appreciate any help you might be able
to offer!

Repo: https://github.com/addyosmani/todomvc/tree/emberjs

[stas]

To be honest, I don't have an answer.
The same question popped up when I added routing support, and I was thinking we should address it to core team, so it should be solved from within the framework.

Maybe just start by opening an issue.

[addyosmani]

//ccing @tomdale and @wagenet in case they're able to help. I could find a hacky way around this issue, but I really feel like there has to be a more elegant way of accessing this data via a template. Any ideas guys?