Open leighmcculloch opened 9 months ago
I tend to agree with allowing more modularity. One benefit is allowing easier integration with other wallets. Right now, TS bindings are expecting a very Freighter-like API for wallets to sign, which could be limiting in the future.
However, as someone who was just tinkering, I did also like having the option of just being able to simply call (as an example from the docs) incrementor.increment()
to simulate and then incrementor.signAndSend()
to sign with Freighter and send it off. As someone who was just trying to get a demo working, I liked being able to already have both the freighter-api integration as well as the rebuild/resimulate/resend "out of the box." I think there's value in having both the fast and easy, we'll-do-it-all-for-you path for newbies, while also having a more modular approach when you're ready to graduate to doing things one piece at a time.
Related: maybe it's worth building an option for the rebuild/resimulate/resend logic into stellar-sdk so users aren't relying on the TS bindings to do that for them. It would make it easier for a dev to move from Option 4 above to a more modular approach if they had fewer pieces of retry logic to worry about.
maybe it's worth building an option for the rebuild/resimulate/resend logic into stellar-sdk so users aren't relying on the TS bindings to do that for them
I believe this issue is doing that 🥳 :
(cc @chadoh please correct me if I'm wrong about that)
This issue was originally discussed in Slack (slack thread) and started by @tomerweller. Moving some snippets of discussion captured over into GitHub issue for more async and further discussion.
My comment above is a little too simplified, as @chadoh has pointed out in the slack there there's other logic currently tied up in the assembled transaction like automatic backoff for sending, rebuilding and resimulating for resending. But I think across both the CLI and the TS bindings, and in general the way the JS and other clients are structured, we need to maintain some modularity so that folks can do all of the things above, and modify state between any of them.
This was originally discussed at the end of November, so if we've already moved on from here and this is out-of-date I can close it. I'm opening this issue to capture the need for us to evaluate if we have sufficient modularity, and if we provide the above different ways to interact with the network/soroban, and to dig into this further if we aren't quite there yet.
I think this issue belongs to the soroban-cli, typescript bindings, and the JS SDK.
cc @chadoh @willemneal @piyalbasu @jeesunikim @Shaptic