<Can> action parameter with empty space does not work

[msedatgungor]

First and foremost, great job with the library. 👏

In my ability file, I defined an ability like following:

can("create space", "ORGANIZATION")

and surrounded a button with necessary Can component as following:

<Can do="create space" on="ORGANIZATION" ability={ability}>

I expected this to work because in @casl/react readme, I saw "read title" as an example for action. But it did not give me necessary permission and hid the button.

But when I replaced space with dash on both of ability and Can definitions ("create space" -> "create-space"), the button appeared.

Should we provide action parameters ("do" and "I") without spaces? (If so, readme also needs to be updated)

or

Is it not a problem at all and should I seek for another possible error that I've made?

Thanks in advance

[stalniy]

Thanks for applause :)

Space are treated specially only in @casl/react and @casl/Vue packages for action prop (do or I)

The thing is when you use readable props (e.g., <Can I=“read title” of=“Post”>...), component splits I prop by space and perceives the 1st word as an action name and the 2nd word as subject’s field name where permissions should be checked on.

So, in that example Im actually checking whether user is able to read field title of at least one Post

[stalniy]

So, yes. Spaces are not allowed in action name but allowed in subject name.

I’ll updste docs thanks!

[msedatgungor]

Then I'll keep replacing spaces with dashes. Thanks for the info :)

Also, before closing this issue, I would like to mention another issue which is also related to docs and relatively more harmless :)

On the first paragraph that you've listed down the action and subject aliases for <Can> component, as following:

I (do is an alias) - name of the action and field
a (on, of, this are aliases) - checked subject

I also struggled to get my <Can> component to work properly because I defined my component's action and subject props with "I" and "on" names respectively and that is because I thought that these are valid aliases. I checked the source code to see if they are valid aliases and that was how I understood the problem: The aliases are limited by some combinations:

type BaseProps = {
  do: string
  on: any
} | {
  I: string
  a: string
} | {
  I: string
  an: string
} | {
  I: string
  of: any
} | {
  I: string
  this: any
};

So I think these possible alias combinations also has to be cleared out in docs. It may be less painful for starters :)