Libraries coming with libraries, coming with more libraries and extra concepts. Unfortunate.
async / await is a prime example for only going the happy path, and completely ignoring the error cases unfortunately.
I think the problem here is that the NextJS bindings rely on Js.Promise.t, and not the advanced Promise.t<'a,'e> implementation of aantron/promise (aka reason-promise).
With reason-promise, you first need to map your promise data to the relevant end result you need, and then convert it to a regular promise, which I believe is done with Promise.toBsPromise.
Alternatively, you may adapt Next.res to use Promise.t<...> instead of Js.Promise.t, which would basically couple your bindings to this particular promise lib.
The whole reason why I made rescript-promise is that ppl don’t have to deal with one extra abstraction. Unfortunately the Relay library dictates the usage of reason-promise here, so no way to make this simpler.
This can often be a bomb waiting to explode in your system. Computations can fail and/or cancel in all kinds of ways, and “ease” can hide these failures. Once the system starts returning values you don’t expect, you have to debug and adapt the code to handle the erroneous paths. This often takes more time and effort than handling these things up front.
Playing the devil’s advocate, but only partially: is it really that bad with async/await? You can wrap the usages in try/catch. And sure, async/await encourages linear style, but likewise, you can write a bunch of .thens without a single .catch.