Client App Schema Validation

[00:00:00]
>> Steve Kinney: Let's go look at the same basic approach, but now on the client, right and you will see the immediate problem that we have to solve, which is, how do I get these types over in the client? But for first, we're gonna start with the most tried, and true method for handling this which is copy and paste, which I'm just moving my problem around in the very beginning, right we've got to figure out how to share them.

[00:00:30]
We'll talk about some of the different strategies, we'll revisit those strategies, we'll undo some of those strategies, entirely different strategy. But let's start with the very least of just seeing the same basic concepts over on the other side, right? So we'll go over to the client, and they're gonna hop over to C comes before S in alphabetical order for those of you keeping track at home.

[00:00:55]
So here we have this type that I just randomly wrote out, which is not going to do us a lot of good because it's accurate, but even partial task isn't really what update or new are supposed to be, it just happens to work, right? But like they're not actually accurate, so we could start out by pulling the pulling in the same types, get rid of this, and now what we could do is for instance, we could take this response.json, right?

[00:01:32]
We could even say like just for fun, const task = await response.json because that's the promise and then what we could do is say, tasks, plural.
>> Steve Kinney: And then return those tasks.
>> Steve Kinney: And this is currently broken because I deleted that reference, it's is also like up there.

[00:02:11]
So let's go ahead and make one based on the schema just like we saw earlier. TypeScript does hoist things, so if you don't want them below, you can also make them up here, it's up to you.
>> Steve Kinney: Cool, and then we can just replace this over here, and what's nice about this is we will get the validation cuz this is now.

[00:02:42]
Always is never any like before, when we saw that initial slide in the very beginning, we were just saying, like, yeah, it's totally a list of tasks. But that's because any will, like, respect anything, and it might have been, it might not have been. Now, this fetch task will blow up if it's not, and you're like, blowing up is bad.

[00:03:01]
Blowing up is better than suddenly being broken, right at least when you blow up, you get a stack trace at an error, right? When things suddenly are weird and broken, it's not as easy, right and then ideally, the next galaxy brain move here there is obviously to then have tests to break the stuff before it goes to production, right?

[00:03:26]
It's like you're always testing, either you're doing it manually, you have automated tests, or you're relying on your users to do it, somebody's testing it. But in this case, we could even get rid of this explicit return type, which are good when you're not sure, right? And it's still the right thing now, right always the right thing.

[00:03:48]
If this thing ever gets something back, that is not the right thing, we will know, and so we have confidence now that we're not just guessing that it's tasks and just being like, sure, sure. It's tasks, like we know that it's tasks because we validated it, right? As opposed to just like trusting, like we verified.

[00:04:05]
So now we have the same approach works in both places.