(no title)
knuthsat | 4 years ago
Using fp-ts there is never a need for async/await and the code is still linear, (Promise is transformed to TaskEither<Error, Result>, similar to the example in the article, although you can ignore the error and just map over the result, handling the error somewhere near the end of the chain).
Problem with async/await is that the syntax is so easy that eventually the whole codebase gets polluted by it, even parts that could have been completely separated.
From the coding perspective, the problem with promises arise when there is a need to bind the intermediate results. You can either store them in an object and return that object for the next .then(fn) call, or you can nest inside a promise. I guess nesting is what annoys people the most (pyramid).
sergiomattei|4 years ago
Curious, why is this bad?
knuthsat|4 years ago
When code is sloppily written you realize that at some point you can't use much of the existing code outside of async.
One nice example of polluting the codebase is having async local storage. Now everything that reads from the storage needs to be annotated async and now your initialization pipeline might be insanely async. Good way to avoid it is to read the whole local storage at the beginning (having a sync interface) and then everyone just reads without await.
From recent experience, I did exactly that with storage and ended up removing thousands of async annotations that were no longer necessary.
Similar "mistakes" happen for other things and then at some point you are putting loading guards everywhere because your async operations are always awaiting and letting the UI update when it should not.
agumonkey|4 years ago
drenvuk|4 years ago
knuthsat|4 years ago