3 ms·
There are some caveats they outline for the usual async stuff[1], but at a cursory glance, it's not that bad. Thanks to F#'s computation expressions, .NET async
by kevinmgranger 5y ago
There are some caveats they outline for the usual async stuff[1], but at a cursory glance, it's not that bad. Thanks to F#'s computation expressions, .NET async code and Fable.Promise code look almost identical.[2]
1: https://fable.io/docs/dotnet/compatibility.html#Caveats-II https://fable.io/docs/dotnet/compatibility.html#Caveats-II
2: https://stackoverflow.com/a/54451205/4099287 https://stackoverflow.com/a/54451205/4099287
- pharmakom 5y agoMy suggestion is to use async in F# code by default. Use task for certain heavy server code on .NET and promise for JS interaction, where required. Async mostly works everywhere.
- kevinmgranger 5y agoIs there some sort of (for lack of a better term) Monad Transformer that lets you mix `async` and `promise` in the same computation expression?
- pharmakom 5y agoComputation Expressions are implemented using a class under the hood so you could probably build one with appropriate overloads. There’s a function that Fable provides to turn a promise into an async, so mix and match isn’t a huge challenge anyway.
- kevinmgranger 5y agoYeah, I'm just trying to avoid having to throw the adapters on each line. Just like fable supports any thenable, it'd be cool if async/task could be treated as a thenable.