dasherize ALL the things: use dasherized model names everywhere

[fivetanley]

use dasherized model names everywhere / change typeKey -> modelName

Previously, we allowed container keys to be loosy-goosy and normalized
them in several places. This commit consolidates those efforts into
one place normalizeTypeKey.

typeKey is now referred to as modelName on snapshot instances and Model
classes. typeKey remains on both of these but is deprecated.

modelName is now a dasherized string, where previously it was
camelCased.

[igorT]

Tests fail?

[fivetanley]

Tests fail?

Yeah, I rebased without re running, fixed the tests that broke. They were expecting a camelCased type when extracting, but it should be dasherized.

[pangratz]

tiny nitpick: spaces around +

[igorT]

Can we add tests that assert this is backwards compatible?

[igorT]

And by we, I meant the awesome @fivetanley :D

[wecc]

camelCase => dasherized?

[igorT]

Why do we have to singularize here?

[fivetanley]

we don't have to, but it's nice

[igorT]

I am pretty scared of dasherizing typeKey, gonna break people's stuff a bunch. Maybe we should go with the modelName strategy?

[fivetanley]

I am pretty scared of dasherizing typeKey, gonna break people's stuff a bunch.

It'd be great to know what people are using typeKey for. Most of the changes in your app code would be comparing against dasherized strings. If we're going to remove this, I'd rather remove it this week than right before 1.0.

[fivetanley]

Maybe we should go with the modelName strategy?

Yeah, just takes more tedious work, but I can switch this over to that.

[typeoneerror]

It'd be great to know what people are using typeKey for.

I'm using typeKey in a handful of cases, specifically for some very hacky polymorhphic relationship handling. One example is the "attachable" polymorphic relationship. I have an action that updates the "attached" model when an image is removed from it. I use typeKey here (I'm sure there's a much better way to do this, but I just did a search in my project and that's where I'm using it):

imageRemoved: function(response, model) {
  let type = model.constructor.typeKey;
  if (response) {
    if (response.hasOwnProperty(type) && !Ember.isEmpty(response[type])) {
      let data = this.store.normalize(type, response[type]);
      this.store.push(type, data);
    }
  }
}

[mixonic]

If _super is not RESTAdapter the return would not be present. It is, seems ok, but is not safe if the parent class is not as expected.

[fivetanley]

👍

[fivetanley]

needs deprecation

[raytiley]

So this breaks everyone's apps that where model-name results in /modelname for the url.

[igorT]

@fivetanley I thought we kept the existing behavior for RestAdapter? None of the tests were changed

[raytiley]

@igorT looks like my app is customizing pathForType fixing it on my end.

[igorT]

@raytiley kinda surprised it broke, would you mind sharing what the problem/fix was?

[raytiley]

@igorT

I had this code which broke whith type='myModel' would now be my-models instead of mymodels.

RESTAdapter.reopen({
  pathForType: function(type) {
    return Ember.String.pluralize(type.toLowerCase());
  }
});

I changed it to

RESTAdapter.reopen({
  pathForType: function(type) {
    var path = this._super(type);
    return path.toLowerCase();
  }
});