DevX of async/promises cross-contract calls

[frol]

I have heard that promises are somewhat hard to use and I just want to have this thread to collect feedback and ideas about this topic for the future improvements.

Historically, we discussed an opportunity to hack into async/await syntax of Rust, but this sounds scary. Alternatively, I have recently read an article about lunatic runtime, so it might be another source for inspiration for someone.

P.S. I only wanted to have a place to collect the painpoints, and I don't expect any actions regarding this idea any time soon.

[austinabell]

Are you referring to the old style or new with 4.0? Details for the changes can be seen on #829 "Updated cross-contract call API"

See #6 for more context on why this isn't feasible. There definitely has to be a larger conversation about the feasibility of this, as it would require turning our contracts into full DSL where sections of the async function are split into multiple calls, which has decently high overhead with a lot of implicit cross-contract calls.

Either way would love to hear about some pain points people have. There are definitely ways our APIs can improve, but also there are some limitations based on the runtime and what functions we have to work with.

[frol]

I think the main concern people have is the fact that they need to deal with the Promises API at all. It would be ideal for the newcomers if the code looks blocking to them.

[coleFD]

Once major pain point I ran into when making a XCC to execute a swap on ref finance was that I could not add a callback to ft_transfer_call() or else the swap would fail. It would execute successfully if I removed the callback (even if the callback didnt do anything) but it prevented me from adding result handling logic, which was critical to the application. It seemed like the callback that I added conflicted with ft_transfer_resolve() on the token contract, so it would revert the swap. This was back in May-June, but we pursued other things since the workarounds would have resulted in a crappy UX. One possible solution could be to add a XCC function to NEP141 that calls a standard function on the transfer originator contract, something like ft_transfer_result(), similar to the way ft_transfer_call()/ft_on_transfer works, but there may be a better core level solution.

Not sure if anyone else had run into this issue, but I couldnt find much support when we were dealing with it