Let's talk about using TypeScript with some of view's, primitive functions that you're likely to run across. First up, let's talk about REF and let's talk about ref in reference to DOM references. So if we have a div and the ref is my diviv, and then we up here, we can do cons. My diviv equals ref. And then once this mounts, this will be loaded into my diviv.

And then once this mounts, this will be loaded into my diviv. But again, we don't have any type inference around this, right? So my diviv value, there's nothing here, right? But we know that ultimately it's going to be a diviv. So we can type it using the generic. So we can say HT ML diviv element. And this just comes bundled right into TypeScript. And then once it's loaded up, you get a bunch

And this just comes bundled right into TypeScript. And then once it's loaded up, you get a bunch of information around it. And if, for example, this was an image, you could do HTML image element, and then you would get a bunch of image specific stuff around it. So super useful to type this. Something I just learned about while making this video is if you have you greater than 3.5, they have a new

Something I just learned about while making this video is if you have you greater than 3.5, they have a new inference based ref system for template refs. Check this out. It's rad. So now you can just do diviv, use template ref, and look, you even get auto complete for the template refs that are in your template in the id, which is so cool. And you say, my diviv. And now this is actually auto loaded up

And you say, my diviv. And now this is actually auto loaded up as a diviv element or null. You don't have to type this at all. It just knows that this is the reference to this div. That's dope. Thank you. View. That's really cool. And then you just get all of the goodies that we just got by doing it manually, automatically with used template ref. Incredible. Very, very, very cool. Let's talk about states. So in react, we have used state,

Incredible. Very, very, very cool. Let's talk about states. So in react, we have used state, but we actually use REF pretty commonly for state in view. So let's talk about it. Ref, I'll say count. And this is zero. So again, just by doing this, it's now inferred that count is a number, right? So if we said can count value and we hover over it, it's going to be a number. And if we try to assign something like hi to it,

and we hover over it, it's going to be a number. And if we try to assign something like hi to it, it's not gonna like it, right? So string is not assignable to number, but what if we want that flexibility? Well, we can just specify the type here. So we can say number or string, and now everybody's happy. But if we try to do true, it's going to bark again. So I would again, use inference as much as possible here. But when you want to get specific

So I would again, use inference as much as possible here. But when you want to get specific or you want some flexibility there, it's nice to tap into the generic of the ref and pass types that you want to specify that value to be. Last but not least, let's talk about computed state. So this is a pretty common one, right? So if we have cons, attributes equals computed, and then we're going to have a little function that returns our computed.

and then we're going to have a little function that returns our computed. So let's do, actually, let's bring back cons. Count equals ref zero. Okay? So we're gonna say if count value is greater than zero return, title, description, right? Okay, sure. And then otherwise return something else. At the moment it's just both the same and it gets inferred as the same.

At the moment it's just both the same and it gets inferred as the same. And if we added something else here, then that also gets inferred, right? So we have title description, sure, but sure could potentially be undefined. This is all well and fine, but to me, when you have multiple return statements, it's a little bit of a red flag. I would love to see a contract that ensures that

it's a little bit of a red flag. I would love to see a contract that ensures that what we're returning is always what we're expecting to return. So let's just turn this into a little contract here and we'll just say title and description. They're both strings, right? So now if I have a typo, it lights up. If I exclude it, it lights up. But if I, if I'm properly returning, it'll be good to go.

If I exclude it, it lights up. But if I, if I'm properly returning, it'll be good to go. And I get some nice auto complete here, which is pretty cool. And just as a reminder, you can pass anything into this generic. So if you want this to be a Boolean, totally fine. Now it's gonna light up red and say, Hey, you're, you're returning objects. Instead of Boolean, you can say True. You could say false.

and say, Hey, you're, you're returning objects. Instead of Boolean, you can say True. You could say false. Great. And now everybody's happy. So that's how you use TypeScript with some common view functions that you're probably likely to use within your view and layer vault application.