Transcript from the "Defining flow-typed" Lesson
>> Brian Holt: So now we have show cart being typed. So let's go do client apt at the top do @flow. The first thing it's gonna say is I don't know what module is, like many of you did. [LAUGH] And that's because it has no definition for that. So I'm gonna go show you how to create your own definitions.
>> Brian Holt: So inside of the flow-type directory, I create a new file called types.js.
>> Brian Holt: This is gonna be a place where you create types that the rest of your project can use. So if you wanted to use module multiple places this is where you would do it. So we're gonna do @flow up here.
[00:00:50] And there's a couple ways of doing this but we're just gonna say for now declare var module.
>> Brian Holt: Hot and it's gonna be accept (path: string, callback: which is going to return void and if itself returns void.
>> Brian Holt: So what we did here is we declared a new type, so this is basically acknowledging this is going to be a global variable, this is how you interact with it, right?
[00:01:31] So it's going to be an object, it's gonna have an object called hot. And the only method that we acknowledge on it is called accept. And it's going to take a path, which is a string, and it's gonna take a function that returns void, which means it's not going to return anything.
[00:01:50] And then it accepts the function itself, returns void.
>> Brian Holt: Any questions about that?
>> Brian Holt: So now, we can use module.hot.accept anywhere in the code, and flow is gonna know about the types that go in and out of it. There's more two module, I don't remember what's in it, but if you needed to use more things you would just come in and annotate this a little bit more.
>> Brian Holt: So, now if we go back to clients app.jsx, hopefully.
>> Brian Holt: Let's see if flow has figured it out.
>> Brian Holt: Yeah, it has.
>> Brian Holt: Settle in there. Sometimes, it's tough tell the difference. No, it's cool with it.
>> Brian Holt: Yep, okay, it's fine. Again, sometimes flow type can be a little bit slow to update with sublime.
[00:03:02] Any questions about type definitions? A lot of times I just put all the types in one file, cuz I usually don't have enough types to make a separate file for each type. But that kind of falls to your discretion. I usually only end up typing five to ten objects, and that's fine.
[00:03:22] Let's go to Landing And we're gonna do @flow and guess what? No changes. It just hopped it into the type checker and it's already good to go. So landing's all checked and good to go. And what else do we need to do, adjust here.
>> Brian Holt: We did Search.
[00:03:51] We did Landing, clientApp. App, App needs to be typed as well. So we're gonna do // @flow up here. And that should be good as well.
>> Brian Holt: So something that's gonna be really cool. That flow just gets you out of the box.
>> Brian Holt: If I start saying something like yeah here like in props I could say props.thing.
>> Brian Holt: And it's gonna give me some tags like hey you don't have any props for this so I'm not gonna let you do this, right? So it's gonna be constantly checking your React, and your props, and your State, a good way of also visualizing this, something that would not otherwise be caught.
[00:04:40] So if I go to search.jsx, I have searchTerm right here. But if I try and say this.state.searchTerm.
>> Brian Holt: Put something that's not on the stream part. Well let's say this is 5 right for just a second say that was a number. Then try and say .toUpperCase. It's gonna say hey you said you're calling two uppercase.
[00:05:11] That's a string thing not a number thing so that's gonna fail. And so your flow typing is gonna start failing. The other thing is notice right here where it says this.setState is trying to set that state to be a string. It's gonna say you're calling setState with a string here, this is a number.
[00:05:27] You're gonna mess things up if you give this a string. How does it know that? Well by doing state like this its gonna type here state implicitly based on the initial strings that are or the initial things are given there, right? So I didn't tell it that search term was a number, it just knows that which is pretty cool.
[00:05:49] So now I change this back to a string and everything is fine because all that works with string. Make sense? So this is gonna catch issues that you wouldn't otherwise see.
>> Brian Holt: So again this is why I say it is work to get flow and TypeScript up and working, but I guarantee you it's gonna save you bugs.
[00:06:12] This just eliminates an entire class of bugs. Like even if I said like this.state.searchterm.toUppercase and I did it lower case like that this would totally fly right? In the sense of this is gonna make it past Lint, this is gonna make it past a bunch of different things.
[00:06:34] But it's gonna get caught a lot sooner by @flow type it's like, hey this isn't a real function so these kind of fat finger or not remembering the k the c here is capitalized all that class of problems gets eliminated by using a type checker. So it's pretty awesome, I'm a fan.
>> Brian Holt: Yeah?
>> Speaker 2: Have you used it in production?
>> Brian Holt: Yeah Netflix uses flow. I would say well and they use typescript as well. It depends on which team you're on but I know Facebook as like over 50% coverage on their flow for their entire code base which is crazy.
>> Brian Holt: I would say Netflix's co-coverage was lower than that, but. Where we found great success is that when we would export components to other teams, we would just ship along with them some flow typings. And so when they were using and consuming those, they were going to be assured that this is how it's supposed to work.
>> Speaker 2: I was asking if all the code from flow typed types.js should be checked in?
>> Brian Holt: Yes, yep it should be.
>> Brian Holt: I think that's the recommendation off the repo, but I mean you can use flow type to install it as well, so you can probably ignore it as well.
>> Speaker 2: And the NPM folder too.
>> Brian Holt: I think so I think that's what they recommend because like as those files get updated even if your code is basing itself on broken types or not broken types just maybe out date types You wanna be explicit that you want to opt into those upgrades.
[00:08:20] It's not like NPM where you're assured that if you pull in this version you're getting this version 100% of the time. It's not so robust cuz really it's just a repository full of types.
>> Brian Holt: So I believe the recommendation from the flow team is to check in your types, and then update them yourself.