Question about the necessity of having an Ember.Object as a resource

[garno]

Hi,

I’ve come across an unexpected behavior today and I wanted to investigate a little more about the cause. We ditched ember-data in one of our projects and, as a result, my route models aren’t instances of Ember.Object. This seems to be incompatible with the current CanMixin helper can.

Here is a dumbed-down example to explain my issue:

// some-route.js
export default Ember.Route.extend(CanMixin, {
  model() {
    return {foo: 'bar'};
  },

  afterModel(model) {
    if (!this.can('edit stuff', model)) {
      window.console.log('Cannot edit stuff, should redirect you.');
    }
  }
});

// abilities/stuff.js
export default Ability.extend({
  canEdit: computed(function() {
    return this.get('model.foo') === 'bar';
  })
});

In this example, this.get('model') will always be null. Which is weird since this is how I've used this library in the past, and it's working when using the Handlebars helper.

I found out that the problem is related to this processing of the arguments which validates if the resource passed is an Ember.Object. If not, it sets resource to null and populate the properties instead.

As for now, the solution I’m using is to simply always pass some properties like this:

this.cannot('edit stuff', model, {});

I was wondering what was the use-case of switching these arguments. So, I have 2 questions:

• Why do resource absolutely need to be an Ember.Object?
• What could be the outcome of my solution since resource is not an Ember.Object?

Thanks for enlightening me 😊

Keep on the good work!

[Exelord]

YEP! This is going be allowed in #79. Thanks for raising the issue!