4 ms·
How interesting! I've been wanting to use fp-ts for a while now. How did you manage to convince your team to give it a go. It's certainly very different than ot
by seer 7y ago
How interesting! I've been wanting to use fp-ts for a while now. How did you manage to convince your team to give it a go. It's certainly very different than other orthodox approaches to React (or TS for that matter)?
Have you had any particular problems / downsides of using it?
And lastly have you considered ReasonML instead? That's the other thing I've been following closely but it never feels quite ready to start working with, for someone not well versed in FP that is.
- girvo 7y agoTo your first question: simply put, the easiest way was slipping in usage of Either<L, R> for handling “successful failure” states; error handling in Typescript is still not fine grained enough, even with async functions (maybe even especially), so Either and Maybe/Option have been a big help. And once you have those, you might as well have them implement the same “interface”, and now you’re cooking with functors ;) No joke, it was error handling in successful promise resolves that made it an easy sell. I adore Reason — I use it extensively myself, but as I also adore OCaml this shouldn’t be surprising. The downside is that it’s a harder sell for a mostly backend team; it can definitely be used to great effect today, but Typescript for all its downsides is easier to use right now. Speaking of downsides: the major one with fp-ts (and io-ts) is some of the inscrutability of it’s more powerful abstractions for programmers who are not well versed in typed functional programming. But that’s okay: just don’t use them! You can get quite far with just the easy to understand concepts, and introduce things like EitherT or Task/IO and similar as the team becomes more confident with composing these data types!