Stuck at 1.1.1 about ember-can

[Exelord]

Im really not sure if you should follow this mete programming solution. I was dealing many times with dynamic abilities and all I needed was just the first solution with a custom constructor.

Registering and deregistering is very hacky :/

[Exelord]

Ability is not a singleton and should not be treated like it. That was a bug in the past that allow sharing one instance of ability between many objects which in result leads to model and custom params overrides and incorrectly resolved permissions.

I think you could just move that logic into the ability constructor. If you need to do it in many places, create a base class for them which defines these props. Do you think that would work? :)

[betocantu93]

Hmm, these props are totally dynamic coming from an endpoint, per ability type, so in order to do that (inside the constructor, or the creation process) I would need to save these props somewhere, perhaps the can service and basically add these props in every .create({})

Ability.create({
...this.configFor(modelName)
})

What do you think?

[Exelord]

What I mean is to get this config inside of Ability constructor:

class Project extends Ability {
  @service session;

  constructor() {
    super();

    this.session.abilities['project']
    // ...define the props
  }
}

You cannot assume that the only place abilities are created is your function. Abilities should be isolated and contain any information they need to be able to construct the object.

So I guess you should keep the config somewhere and inject it into abilities so that they can use it during construction.

There is also another option (I think so). You can try to create an Ability class dynamically and register it on demand. Its a meta-programming (depends from your opinions about it).

[betocantu93]

Both good options, @Exelord thanks for the follow-up, the last characteristic is that we also do have some hardcoded frontend props, so these dynamic classes would need to extend the hardcoded ones.

//abilities/project.js
export default class Project extends Ability {
  get canIndex() {
    //some frontend specific validation
      return window.onLine && this.model.role == "admin"
  }
}
//services/session.js
export default class SessionService extends ESASession {
  augmentAbilities() {
     //some meta programming for all ability types
     abilityTypes.forEach(abilityType => {
      //...stuff
      let CurrAbilityKlass = getOwner(this).factoryFor(`ability:${abilityType}`).class;
      let ExtendedAbilityKlass = CurrAbilityKlass.extend(someDynamicProps);
      getOwner(this).unregister(`ability:${abilityType}`)
      getOwner(this).register(`ability:${abilityType}`, ExtendedAbilityKlass)
    })
  }
}

Looks good?

[betocantu93]

Although this might at some point cross-pollute between extends (imagine we are polling this permissions endpoint) in a worst case scenario, perhaps the factory should instead be lookedup via literally require.entries, to be sure we're always extending from the hardcoded one

[betocantu93]

you're right, i'll follow your advice, thanks!