react-acl vs CASL

CASL and @piplup/react-acl both decide what a React app shows each user, with a Can component and a hook. They model access differently, and that difference decides which one fits.

• CASL checks an action on a subject, and a rule can carry conditions on the subject's fields: "may update a Post whose authorId is mine".
• @piplup/react-acl checks permission names such as post:update, with : wildcards and roles. It doesn't look inside records.

This page compares @casl/ability 7.1 and @casl/react 7.1 with @piplup/react-acl 4.1, as of November 2026.

At a glanceCopy Anchor Link

The same check in bothCopy Anchor Link

Hide a Delete button from users who can't delete posts. With @piplup/react-acl:

import { AccessControlProvider, Can } from "@piplup/react-acl";

const principal = { roles: ["editor"], permissions: ["post:read", "post:delete"] };

<AccessControlProvider principal={principal}>
  <Can permission="post:delete">
    <DeleteButton />
  </Can>
</AccessControlProvider>;

With CASL:

import { createMongoAbility } from "@casl/ability";
import { AbilityProvider, Can } from "@casl/react";

const ability = createMongoAbility([
  { action: "read", subject: "Post" },
  { action: "delete", subject: "Post" },
]);

<AbilityProvider value={ability}>
  <Can I="delete" a="Post">
    <DeleteButton />
  </Can>
</AbilityProvider>;

For a yes-or-no check like this one, the two are about equally short.

When the rule depends on the recordCopy Anchor Link

Now editors may delete only their own posts. CASL puts the condition in the rule and checks the post itself:

import { AbilityBuilder, createMongoAbility, subject } from "@casl/ability";
import { Can } from "@casl/react";

const { can, build } = new AbilityBuilder(createMongoAbility);
can("delete", "Post", { authorId: user.id });
const ability = build();

<Can I="delete" this={subject("Post", post)}>
  <DeleteButton />
</Can>;

@piplup/react-acl has no conditions, so the record comparison is your code. A separate permission name describes the narrower grant:

import { useAccessControl } from "@piplup/react-acl";

function PostActions({ post, userId }: { post: Post; userId: string }) {
  const { can } = useAccessControl();
  const mayDelete = can("post:delete") || (can("post:delete:own") && post.authorId === userId);

  return mayDelete ? <DeleteButton /> : null;
}

That's fine for a few rules like this. When many rules depend on fields of the record, CASL keeps them in one place, and your server can apply the same rules to database queries with @casl/prisma or @casl/mongoose.

While access is loadingCopy Anchor Link

Permissions usually arrive from an API after the first render.

CASL's Can has no loading state. An ability with no rules denies everything, so content wrapped in Can stays hidden and any not fallback shows until the rules arrive. Keep your own loading flag if users shouldn't see a denial first.

@piplup/react-acl treats an undefined principal as "not loaded yet". Its Can renders a separate loading slot instead of fallback, and useAccessControl returns loading: true:

<Can permission="post:publish" loading={<ButtonSkeleton />} fallback={<RequestReviewButton />}>
  <PublishButton />
</Can>

See Not loaded, versus no access.

TypingCopy Anchor Link

CASL is typed through the ability's generics, which list the actions and subjects:

import type { MongoAbility } from "@casl/ability";

type AppAbility = MongoAbility<["read" | "update" | "delete", "Post" | "Comment"]>;

You pass AppAbility wherever you create or read the ability, such as useAbility<AppAbility>().

@piplup/react-acl is typed by augmenting the package once. After that, Can, can() and the check functions accept only your names, with no type argument at each call:

declare module "@piplup/react-acl" {
  interface PermissionsDef {
    "post:read": never;
    "post:delete": never;
    "post:delete:own": never;
  }
}

See Typed permissions.

Which should you choose?Copy Anchor Link

Choose CASL if:

• Rules depend on the record: owners, teams, statuses, dates.
• You need field-level rules, or explicit deny rules with reasons.
• You want the same rules to filter database queries.
• You also use Vue or Angular.

Choose @piplup/react-acl if:

• Your backend already speaks in permission names, such as OAuth scopes or a roles table that expands to permissions.
• You want post:* style wildcards without listing every action.
• You want a loading state in Can and useAccessControl without extra code.
• You want a small package with no dependencies.

Whichever you choose, the UI check only hides things. The server still has to enforce the same rules on every request.

FAQCopy Anchor Link

See alsoCopy Anchor Link

• Role-based access control in React
• Permissions and wildcards
• Can
• CASL documentation