Use assertion functions inside classes
Assertion functions are pretty useful when they're applied to classes, and there's some cool stuff you can do. Here we've got an SDK
It's kind of like if you imagine the back ends at a center point where you invoke class and you've got all your methods and stuff.
And here we've got a loggedInUserId and this can either be string or it can be undefined. When it's undefined it means the user isn't logged in and so there might be still anonymous things they can do.
But inside createPost we want to assert that the user is logged in and there we're going to use. the user ID. But the issue here is that we've got string or undefined in for the first argument of the call to createPost which is not good because actually we need string and really we've asserted that the logged in user ID exists.
So we should just be able to get this going. But we haven't told TypeScript that this.loggedInUserId is defined. If we were to move the if statement in our assertion to be inside createPost here then it would work.
But how do we get this. kind of inference working? Well we can return asserts this is this &. Which means we are saying assertUserIsLoggedIn is an assertion function now and we're saying that this is this and something else and we can add loggedInUserId: string
What this does is it basically just adds an intersection to the class. and matches them both together and loggedInUserId: string wins. So we get the string inside the SDK and now this.loggedInUserId is typed string.
We could probably do even something more in here. We could say wow which is a Boolean. And then use this.wow in createPost
So assertion functions are pretty useful. We do need to make sure that you check everything there. Like this.wow Boolean is technically unsafe.
But, it does give you a lot of flexibility and it means you can use it in a lot more of a reusable way.
Transcript
Assertion functions are pretty useful when they're applied to classes, and there's some cool stuff you can do. Here, we've got an SDK, which is like, if you imagine, the back end centerpoint, where you invoke this, and you've got your methods and stuff.
Here, we've got a logged-in user ID, and this can either be string, or it can be undefined. When it's undefined, it means the user isn't logged in, and so there might be still anonymous things they can do. Inside createPost, we want to assert that the user is logged in.
There, we're going to use the user ID. The issue here is that we've got string or undefined in this position, which is not good, because actually, we need string. Really, we've asserted that the logged-in user ID exists, so we should just be able to get this going, but we haven't told TypeScript that this is defined.
If we were move this stuff inside here, then it would work, but how do we get this inference working? Well, we can return assert this is this, and -- so we're saying this is an assertion function now, and we're saying that this is this and something else, and -- we're going to add logged-in user ID, string.
What this does is it basically just adds an intersection into the class and matches them both together, and this one wins. We get the string inside the SDK, and now this is typed a string. We could probably do even something more in here. We could say wow, which is a pretty Boolean, and I'm pretty sure we'll be able to go this.wow, which is a Boolean.
Assertion functions are pretty useful. You do need to make sure that you check everything there, like this wow Boolean is technically unsafe, but it does give you a lot of flexibility, and it means you can use it a lot more way of a reusable way.
You can do some really, really neat stuff with assertion functions inside classes.
Here, we assert that the user is logged in and get proper inference on the user's logged in user id.
