Conform a Derived Type Without Losing Its Literal Values
Deriving vs Declaring is key to getting the most inference out of your types with as few lines of code as possible.
But sometimes, you want to ensure that some code conforms to a type without losing its literal values.
Enter satisfies()() 👀
Transcript
0:00 A golden rule of effective TypeScript is you should always try and derive types instead of declare types. Here, we're creating this user actions array, where we already typed the enum for the type of actions that the user can do, and the type of role that you need in order to do them.
0:16 I think there's a better way to do this. Here, we've started obeying the golden rule, which is we're now declaring the user actions as a const, which means they're not going to change. There's a static configuration. We're now deriving the action and the role from the data structure that we have already.
0:34 There's a problem here, though. With user actions declared the way it is, it's not actually enforced what type this configuration should be. This type can technically be anything, and if I accidentally add this as a role here, then we're going to get this obscure type error down at the bottom here.
0:48 The issue is, if I add a type annotation up here saying what sort of vague type I want it to be, we first of all get an error up here, but we also get errors down here in that they're now typed as string instead of the actual const values that should be there.
1:03 We can do something really smart to cover this. I've created this satisfies function here. What this allows me to do is pass in a generic to say, "This is the kind of thing I want to accept." Then, when I actually call the function, it allows me to pass in a narrow version of that generic.
1:20 What it's going to do is it's not going to return a number here. It's going to return two, but it enforces that two is at least a number. For instance, if I pass this in here, then it's saying it's not assignable to type number. What this means is that I get the best of both worlds. I get to vaguely say what I want in this slot, and then also get the narrow inference here.
1:41 With the config that we defined before, we can say this very loose shape of generic here, and then we still get all of the deep inference right there. If I delete one of these things, it's going to give me a type error, because I didn't add the roles property.