Benefits & Limitations of CASL

[00:00:00]
>> Kyle Cook: So we have 1 to 1 feature parity between our original built system and the CASL system, and as you can see, there's not a huge difference in how you use these systems. It's really all about how you set them up. So let's talk about the difference between them and the pros and cons that we see inside this system. So the very first thing you get with CASL is you get these advanced conditions. Like I said, you can use things like not equal, in, and so on to do more than just simple equality.

[00:00:24]
Now if you were to do this, you need to make sure that when you write out your Drizzle conversion like we did for databases, that you handle not equals in and so on. But as you can see, adding a new line into this section, if we scroll down, adding a new case statement and a single line function is really not that much work to add into your system. Also, we don't have to handle nearly as much complicated TypeScript.

[00:00:47]
There is still TypeScript code that we have to handle, but it's much simpler than when we wrote the system entirely on our own, and you alleviate yourself of all the headaches of dealing with that overhead of maintaining a system as well as maintaining your permissions for your application. The big drawbacks of CASL, number one, we have a huge reliance on classes. You can already see where we ran into some of the problems with that subject-based stuff.

[00:01:08]
And speaking of, I should show you what happens when you don't do what we did. So let's go to one of our pages where we have a subject being passed along, so we'll do our edit page here. And if I were to come in here and I do not actually pass this along as a new object, I just pass it along as is, if we go to this project edit page, we're going to get an error thrown for us. So let's sign into an admin user, go to the edit project page and immediately you can see we get an error from Next.js essentially saying client components cannot pass classes down from or server components cannot pass classes to client components.

[00:01:40]
So this is why we essentially created a brand new object every time we passed along to this subject function. So that is another huge downside to CASL, and like I said here, the React server component compatibility. There is a way you can get around this. What you can do is when you call the build function inside of CASL, so I'll show you where that's at. Scroll all the way up your ways. Here we go.

[00:02:05]
When we call build, you can actually pass along a detect subject type function, and this allows you to essentially add your own custom subject type onto each thing. So here we can call detect subject type and pass along our own custom type, and then whenever we access data from our database, we just need to make sure we have pinned that on to each one of the values we get from our database. Then you no longer need to wrap things in a subject because CASL looks at your object, sees this CASL type, and whatever that string is, is what it assumes your subject is going to be.

[00:02:36]
I find this a little bit messier because now all of your data in your project is going to have these CASL types strewn throughout it. So I just go with the subject approach, but depending on what you want and how much of a nuisance this is, either option A or B will give you the exact same result. It just depends on how you write your code. Now, finally, something I didn't really quite list here is you also have less TypeScript safety.

[00:02:58]
I kind of already showed this a little bit, but when you actually define things, for example, inside of here, I don't get any type safety on what my different conditions are going to be inside of this system, and I don't get type safety when I actually do things inside of looking at my, let me find a page, here we go. When I do this for my types, I don't get any type safety here on my fields, so you are limited in your type safety compared to the system that we wrote as well.