@casl/ability@5.1.0-next.11
Pre-release
Pre-release
5.1.0-next.11 (2020-10-17)
Bug Fixes
- README: removes explanation duplicated from intro guide (6315aa7)
Code Refactoring
- ruleIndex:
detectSubjectTypeoption is now responsible only for detecting subject type from objects [skip release] (ebeaadc)
BREAKING CHANGES
-
ruleIndex: string and class (or function constructor) are the only possible subject types for now.
detectSubjectTypeis now responsible only for detecting subject type from objectBefore
When providing subject type it was important to handle cases when passed in argument is a string or function. As an alternative it was possible to call built-in
detectSubjectTypewhich could catch this cases:import { Ability } from '@casl/ability'; const ability = new Ability([], { detectSubjectType(object) { if (object && typeof object === 'object') { return object.__typename; } return detectSubjectType(object); });
After
There is no need to handle subject type values in
detectSubjectTypefunction anymore. It's now handled internally:import { Ability } from '@casl/ability'; const ability = new Ability([], { detectSubjectType: object => object.__typename });
Also it's important to note that if you want it's no longer possible to use classes and strings as subject types interchangably together as it was before. Now, if you want to use classes, you should use them everywhere:
Before
import { defineAbility } from '@casl/ability'; class Post {} const ability = defineAbility((can) => { can('read', Post); can('update', 'Post'); }); ability.can('read', 'Post') // true ability.can('read', Post) // true ability.can('update', Post) // true
After
import { defineAbility } from '@casl/ability'; class Post {} const ability = defineAbility((can) => { can('read', Post); can('update', 'Post'); }); ability.can('read', 'Post') // false, 'Post' and Post are considered different now ability.can('read', Post) // true ability.can('update', Post) // false