Overriding via provide in a plugin causes strange behavior in templates about casl HOT 19 CLOSED

You can use any ability instance. It can also be PureAbility. This is just what my fingers now to type ))

let me know if you will have further questions

from casl.

Hello,

are you sure you can change providers inside watch? I don't think it's a valid syntax. Instead of providing a new ability on every thing change, you need to update existing ability

from casl.

inject inside child components happens at setup time. and setup is called (very likely) once per component, until it's destroyed.

from casl.

Hello,

are you sure you can change providers inside watch? I don't think it's a valid syntax. Instead of providing a new ability on every thing change, you need to update existing ability

Yes it is valid syntax to call app.provide in a watch inside a plugin. Anything available here is valid. This includes provide and runWithContext (similar to inject).

Provide should be updating the existing ability. When I actually get the ability inside my component during setup it is the correct ability. When calling it without actually providing the can from the ability object though, it is providing the error. From what I've read through the repo and elsewhere this seems to be from a null ability being called somewhere.

from casl.

Can you prepare some live/github example for me to look into this issue?

from casl.

By the way, I can’t find in official docs that multiple calls of provide will provide a new value. That say if you want reactivity - use refs.

from casl.

Can you prepare some live/github example for me to look into this issue?

Yea I'll see if I can find some time next week to try to reproduce it in a gist or something.

By the way, I can’t find in official docs that multiple calls of provide will provide a new value. That say if you want reactivity - use refs.

It does though. You can test this by using any app level or component level provide with the same injection token twice.

I was actually thinking about using the ability in a ref just in our own plugin and providing reactivity through that. I was curious why this wasn't the route taken with the current plugin?

This is how your plugin works when updating the ability value. I don't understand the confusion? Source

from casl.

In fact, since we check in usAbility for the ability to be null before injecting it in the component I don't know how the error I'm running into actually happens https://github.com/stalniy/casl/blob/master/packages/casl-vue/src/useAbility.ts#L10

from casl.

Here is a REPL that demonstrates some of the behavior that I'm talking about. Here it is nondeterministic to get the relevantRuleFor error but it does show some of what I'm talking about. In this particular instance it is caused because the ability defined by the library isn't a ref so the page isn't reactive to the changes made for the abiility. But for instances like this, where a reactive change needs to happen to define the can provided by the composable how are we supposed to update this so that we can use can and the Can component with the library? I have to update the ability defined for the current user on the fly for a couple of reasons (permissions change arbitrarily, not defined by login on a login component specifically) so I need to be able to update this ability at will using the watch.

Should I just use a ref and essentially write my own plugin and not use the casl defined one? How would I be able to use the Can component in that instance?

from casl.

Have you seen this example https://github.com/stalniy/casl-examples/tree/master/packages/vue-blog ?

from casl.

Yea, we don't use Vuex so the state modifications don't apply and won't fix the issue for us unfortunately :/ we were thinking about plugging in Pinia at some point but it's far off.

from casl.

Typically in vue plugins you provide a ref, I'm confused as to why you built in something different for this plugin? The reactivity problems would be eliminated by using one and I think it'd still be compatible with vuex, etc.

from casl.

It has nothing to do to vuex. Plug-in is built in the same way it was built for Vue2. You don’t need ref to track ability changes. Reactivity is built in inside Ability

from casl.

Can you show me an example of that? This in your vuex code is providing the reactivity and updates for your abilities.

from casl.

The stored ability is a singleton in that example which gets pulled from and updated by vuex. If you just pull the ability elsewhere as I've done in the example I've shown the updates don't properly propagate.

from casl.

Unless you use the composable for the provide function which updates the ability within the plugin. Which should be the same behavior I have in the plugin I've written above, I don't understand how it's not updating.

from casl.

I looked into the code and now I understand the reason. You did manually provide ability instance via your custom plugin or whatever but instead you should use abilitiesPlugin from @casl/vue which makes ability to be reactive under the hood -> https://github.com/stalniy/casl/blob/master/packages/casl-vue/src/plugin.ts#L15

If you do this, you will no longer see the error. The error happens because can and cannot are not bound to this by default and only plugin binds them.

from casl.

When I try to setup example similar to yours, I see 2 issues:

1. Vue warns that ABILITY_TOKEN has been provided and will be overwritten.
2. Child template is not re-rendered re-setup and it uses the old can method which is bound to the previous Ability instance when app.provide provides a new instance of Ability. That means, provide is not reactive and when you provide new value, you also need to force re-render the whole app.

What you should do instead is this:

Then reactivity works as expected and you can do this in components:

from casl.

Ok, I will try that. Thank you! Why do we have to use createMongoAbility? I don't have anything related to Mongo in my app, hence why I was using PureAbility.

from casl.