Export this, and in the menu, I'm going to turn this into deep-read-only. So far, I haven't achieved anything. There are no differences because read-only is just a copy of what the original read-only was. But what I can do now is I can say, well, everything in here nested, every property also becomes read-only, which means it will loop over any object in there. So, if there are any nested objects in there, they will again become read-only, and that will go through however nested many levels you want. So, if I save this, we immediately get a couple of other errors. The second one we'll fix in a moment. But this one, where it says, well, we can't change the price and we're actually changing the price on the first beta, multiplying it by 10 every time. That's an assignment we don't want. So, let's actually go there, pizza shop, and that's the second thing. There are two more errors we have to solve. You can actually solve that relatively simple. Right here, we've got the pizza, which is a deep root only pizza and we're adding that to the pizza or menu. But if we look at the definition of that, that's just a regular pizza, which means we're taking a read only version of pizza and assigning that to a non-read only version. So, in this component, we could theoretically start changing that pizza. So, by adding the deep read only here as well, that should be fixed and safer as well. And fix my typo. So, now those errors are gone. And if I accidentally, for some reason, I wasn't doing that, but if I did something like pizza.price is one, for instance, now right here, that's a compile error saying, well, it's read only, it can't be changed. And if I undo this change for a moment, now this would be perfectly legal. You shouldn't do that. Never in React, change props being passed in, but TypeScript thinks this is legal because it isn't aware of that rule. And now it won't, it will stop us. So no more compile errors. The problem with the pizza margarita should be gone. 795, it's still 795. So by adding a bit more explicitly what we intend to do with types in TypeScript. We actually found two more books in the code, which is pretty neat. Now, in the interest of time actually gonna change this for a moment to what we had before. Because we've just got 10 minutes left so I won't be able to demo this and I think it's kind of nice. Here, I had the pick of the pizza and I want to the price and the name and pick with the K, not an L. And like what I was previously mentioning, if you look at this it's hard to see some. Well, pizza is read only so we'll make this read only if I can type read only. That's lowercase O, yeah. So this pizza only becomes read because now we can see how it's defined, it's a pick read only of properties with some picked and then some other stuff added. But what does that actually result in? Well, I can't really tell without manually or at least in my mind going through all the stuff in there, which is kind of hard. Now let me skip ahead in the slides a bit to the next part where I was gonna display the type because there's this other really neat utility, Resolve, which is from Dan van der Kam in his book, Effective Type Script. And if you scroll down a bit, there is this resolve type, which basically says, okay, resolve a type from its definition to what it's actually defined as. So I'll copy that, paste that in there. And now I'm basically gonna wrap this whole structure inside of resolve. If we look at the pizza on order now, I don't see read only or mid-pick, any of that stuff. I see kind of what it boils down to with name, price, and next ingredients. I can't see the details on the extra ingredients yet because the structure isn't recursive, just like with the deep read only, I can say well also go and resolve the nested stuff in there. And now, if I look at the pizza on order, I can see exactly, well, there was a read only name, price, there's an extra ingredients, but not read only, there is a read only name and price there. So apparently this should also be a deep read only in order to make the extra ingredients read only, or I just specified in here like that. So now I get to see exactly what the result is. Now someone pasted a type definition, which I'm not familiar with in it, but I suspect does exactly the same thing, so let's see. If I use that, yeah, it does exactly the same. So different way of achieving the same goal. I'm not sure why the one from the special cases functions, I don't think it actually needs to. I think if a change is back to resolve and actually say, well, forget about the function, we'll forget about the function parts that, well, this case, it's certainly gonna work because there are no functions in there. But I think in other cases that will work just as well. I've never really investigated that I just used this as is with the nested structure on there. Interesting, it gives you no runtime overhead because this is purely TypeScript and it's gone at compile time. It does make compilation slightly slower, but I think the fact that you can see what the result is makes it really powerful over having to infer yourself what the result of all that pick and read-only, et cetera. So, I typically use this quite often on Types to see this stuff. So, we've got five minutes left. Let's do these last two exercises in one go, adding the resolve, or this expand recursively, whatever you prefer. That's in the chat window. So the useful alternative. As far as I can tell, there was no benefit to one or the other. They do the same thing. And at the same time, add a deep read only to find the two bugs in the code, which I just fixed. And then after that, we'll wrap up the workshop. And then, I remember we skipped, so we didn't get to the last part, but you'll have coupon code for the course. And I already noticed from my alerts on my phone that quite a few people already registered for that, but that's fine. That's what it's for. So I'm gonna skip over the last bit, which is interesting, but unfortunately we didn't have time to cover everything, which I predicted upfront, but that's what the course, the online courses for you can still see those modules there. There are about the parts down here. Where's my mouse there? The type predicates and assertions, which will give you both compile and run time safety, and then exhaustiveness checking to make sure where you add something, for instance, to an enum, and you need to cover all the cases with say a switch statement, and you've expand the enum that you don't forget to expand to related switch statements.
Comments