If you’ve read my previous posts, I’m a JS web developer. I live in a sprawling world of open source libraries and dependencies through NPM. But sometimes although there’s a library that does the job well enough, I like to build it myself, and so should you.
Let’s say you want a function that loops through an array of strings and returns you an array with the string from the previous array but they’re now all capital cased. It’s pretty trivial I know but stick with me. What’s your first instinct on implementation?
Every now and then I get asked what level of testing code coverage I aim for in my projects. I usually answer with, “it depends” and follow up with my explanation of how it’s case by case and depends on what the area is, how critical the code is, what it’s for, etc. But what I really want to say is, “who cares” because it simply doesn’t matter.
When I say code coverage I’m referring to the level of testing that has gone into a piece of code, that defines the lines it covers, if it covers every logic branch…
If you’ve decided to add Flow to your toolchain, you’re well on your way to a more stable and reliable application with less runtime errors. This post will guide you through setting up Flow along with giving you a head up to the many early gotcha’s that projects typically face.
It’s 2020 and you do a search for “state of flow in 2020”. You’ll find some blogs from Flow, maybe some blogs comparing Flow with TypeScript, some unrelated stuff with the keyword “flow” and maybe this blog. Really not that much.