2 ms·

React Suspense, with hooks and fp-ts has given our team a massive leg up in terms of rapidly building out our products new front ends. Being able to combine typ

by girvo 7y ago

React Suspense, with hooks and fp-ts has given our team a massive leg up in terms of rapidly building out our products new front ends. Being able to combine typed functional programming with the functional-like abstractions given to you by React nowadays makes for a very nice, very straightforward to debug app, without bringing in dozens of dependencies to get this behaviour. Ant Design has also been a game changer for us.

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 ago
  To 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!

by girvo 7y ago

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 ago
To 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!