Falling In Love With Flow
Click here to share this article on LinkedIn »
I experimented with Flow (a static type checker for Javascript by Facebook) years ago and though “meh.” My code editor would crash, I didn’t see obvious benefits and it was kinda of getting in the way of making progress so it fell to the side.
Fast forward to last week, I decided to take another pass at Flow. I had settled into using a new editor (Visual Studio) and maybe this one can handle running Flow. It can! Here’s an example of a React component that uses it for props and state.
I like this setup because it keeps the component file shorter and you can use these types annnnyywhere. For example if you had a script that uses the same api client that you use in your frontend, you can use the same type for both of these.
But Bro, Typescript
True bro, so true. Typescript handles type checking, it’s built into the name! I like to stay as close to “raw” Javascript as possible. So I write in ES6 and transpile to ES2015. Also, there’s more support everywhere for Javascript so it’s easier to find solutions to problems; the surface area of Typescript just isn’t there. So, bro, have fun with your Typescript, it definitely feels a lot more like Java than ES6 but I’m going to stay close to the action on this one.
The Real Turning Point
I started playing with Flow yes, but it didn’t help much, other than nice auto-complete suggestions I wasn’t getting a major benefit. I didn’t have a glaring “Hey idiot, this interface is wrong” that is the promise of using type checking. Until I was debugging another project…
This other project has a bunch of files containing a function that you would pass some html to and it would return an object. Here’s a rough outline.
Now, there are cases where some sites (Alexa random laugh), don’t want this to be easy. Sometimes requests fail, sometimes other things happen… But this post isn’t about all that, it’s about static type checking! When we detect a failure in the extractor and can lazily “retry” by doing this.
Yes yes, I should pull out onnnly the url and not pass the entire object, yes this is lazy, but it works! Ideally we developers would have time to make all code perfect, but we don’t and I’m not about to pretend that I do.
Now, there was a bug in one of these extractors. Requests were failing, but we weren’t retrying. Hmm. Let’s take a look at a simple version of that failing extractor.
Side-by-side the bug is pretty obvious. I’m returning the wrong thing! links is not a property on the meta object! So the check for links on the returned object sees nothing and with great sarcastic surprise a whole lot of nothing happens. After my recent re-exploration into Flow this triggered a Flowbulb. This would have been easy and obvious if I had used Flow for this file. So what does that look like?
Here’s the error I got when I added the types without fixing the bug.
Now, Flow would still give an error after fixing the bug if I pass back meta the lazy way as the only element in an array on the links property. Since I only specified url in the Link type it would warn me about that, which is great. One day I’ll update all these files or change the interface and when that happens I’ll undo all the lazy.
Use Flow
It’s not just for rappers and liquids, we can all use it and after this experience I’m a big Flow advocate. It’s become a primitive to any Javascript project we start in the future and Container Labs and we’re adding it to existing projects as we work on those as well. Go check it out.
