Improving the Route#serialize behavior


#1

I’m reposting this here from a PR (https://github.com/emberjs/ember.js/pull/2933)

It seems to me that we could make the default serialize hook smarter about how it gets information from the model. Consider the following (slightly simplified) code extracted from my own app that browses a list of Github repos:

Github.Router.map(function() {
  this.resource('repo', { path: '/:owner/:name' });
});

Github.RepoRoute = Ember.Route.extend({
  model: function(params) {
    return Github.Repo.find(params);
  },
  serialize: function(model, params) {
    return { owner: model.get('owner'), name: model.get('name') };
  }
});

Template:

{{#linkTo 'repo' repo}}{{repo.full_name}}{{/linkTo}}

The serialize hook could be intelligent in cases where the data and URLs are not structured around IDs but other properties on the model. If I define my path as /:owner/:name it would try and construct the URL using model.get('owner') and model.get('name').

Thoughts?


#2

I agree, that seems like a good default behavior for the serializer. We’re in a similar situation, except we have a composite key.

Then people whose models don’t match the slugs override the serialize hook still (probably without the params that you have in there, I think that’s just a typo though) to provide the correct behavior.

At the same time it’d be nice if the find methods supported more than just id etc, I’m always having to override it as well, but I guess that’s a different issue.


#3

:+1:

{{linkTo}} behavior is already a bit better thanks to @machty, who joined his and mine work to make linkTo arguments bound. This is a great improvement, but attribute used in serialize is still not bound.

With your patch and with changes from #2252 we could make the situation even better. In such case, people would have to do something only in case where they use something different than id and they use properties different than specified in the router.

The only problem I can see here is that usually you use camelized names for properties, while you use underscored versions for URL attributes. If someone does it differently it may be hard to track and confusing.


#4

I finally had a chance to write up a proper PR: https://github.com/emberjs/ember.js/pull/3134

I can also the camelized vs underscore properties issue. I’m happy to add a conversion to camelcase to the PR if everyone thinks it makes sense… It is easy enough to change.