[pyre]

> Deep linking - unreliable

The deep-linking example comes across to me as an issue of setting up initial state. Loading those other routes first either loads data or modifies the state of the application in a way that is required to display that route.

(or the author doesn't understand the difference between example.com/path/to/route and example.com/#!/path/to/route, but seeing as it "works 50% of the time" it's probably not this)

[aokolish]

Hi there. I omitted the hashbang just because I find it ugly.

> Loading those other routes first either loads data or modifies the state of the application in a way that is required to display that route

That should be a non-issue as far as I understand, because visiting a nested route causes the parent route code to be executed first. Hence, the confusion.

[pyre]

Yes and no. Depends on how the routes are structured in the code. In your example:

  /users/
  /users/15/
  /users/15/photos/

Your router map probably looks like this:

  App.Router.map(function() {
    this.route('index', { path: '/' });
    this.resource('users', { path: '/users' }, function () {
      this.route('index', { path: '/' });
      this.route('show', { path: '/:user_id' });
      this.route('photos', { path: '/:user_id/photos' });
    });
  });

This translates into a structure like:

  ApplicationRoute
    IndexRoute
    UserRoute
      UsersIndexRoute
      UserShowRoute
      UserShowPhotosRoute

Note how all of those Users*Route classes are all siblings rather than in parent-child relationships. Also note that if you're sharing controllers, they won't pass through Route.setupController on the sibling routes because those routes aren't run.

[aridiculous]

I agree that it's probably user error in this case, but also am very surprised this isn't covered better in router documentation. I've run into this problem many times and there's still no authoritative source on how to do it properly.

[pyre]

Just to be clear: I'm not apologizing for Ember.js. There are lot of warts, and having actually built things in both Ember.js and Angular.js, I would have to say that I much prefer Angular.js.

For example, "Silent Errors" is spot-on. One example of an error (technically Ember-Data, but they are pretty much joined at the hip):

  1. Save data for a particular model.
  2. The data actually gets sent to the API and saved.
  3. The API returns the updated model data.
  4. Ember.js fails to load the updated data.

Turns out that the model was created with `store.createRecord('ModelName')` instead of `store.createRecord('modelName')`. Adding the capitalization to the first letter failed to raise any errors and worked in all but one place in the code. This took me a couple of hours of basically debugging Ember-Data internals (and even thinking that I had found a bug in their data loading) to figure this out (which was also difficult since some of the key methods are only generated at run-time so it's difficult to search the codebase for them).

[jakecraige]

The problem is that "Silent Errors" is not spot on. At least not his example of them. If you have this example in angular, you'll get the same result.

$scope.myObj = {x: 2}; <div ng-bind="myObj.notHere"></div>

(forgive me if my syntax is off a bit, haven't written angular in awhile)

The example he gave is an object not having a properly on it that he's trying to access. Any javascript templating language will have this issue

[aokolish]

Correct. This is no fault of Ember's; it's just a characteristic of the language that I dislike.