Feature req: Queueing txs to send
pi0neerpat opened this issue · 2 comments
Hey guys it's me again, here to bother you. One feature that would be cool is the ability to queue up transactions that have already been signed by the user, and are waiting for a previous tx to confirm, before sending.
Scenario
user wants to call a contract function which will spend their DAI (such as rDAI mint). First they need to call approve on DAI, and wait for confirmation before submitting the mint.
Typical UX: sign, wait, sign, wait, done
Better UX if you batch the sigining: sign, sign, wait, done
Since we get all the signing out of the way first, it makes the experience much smoother, since there is only one "waiting" period for the user.
Options
Since the user may navigate away from the page, we need to store the second signed tx until the first one confirms. You can either send it to an external server to do this (booo, too centralized).
OR
We can store it in local storage using Subspace. Anytime the user is on any page, Subspace can check if there is a tx waiting to be confirmed, and submit the next sequential one if necessary.
contributing
I plan to implement this idea in my dapp anyways. Depending on your thoughts I'd be happy to share the code and maybe this is something worth contributing to.
Hey there, @pi0neerpat
This looks like an interesting idea, Currently Subspace is more of a tool to read the contract state, and query balances, but extending it's use to support async interactions with contracts as well would be a really nice addition!
If you don't mind, share your code, or feel free to send a PR this way! :) we'll probably discuss about this feature soon along with the 2020 roadmap for Subspace!
Thanks for the suggestion!
I ended up just submitting both approve + mint at the same time, and just incrementing the nonce. I didn't end up needing anything fancy like this.
However storing tx and monitoring status would still be cool. I would use it to let users navigate away and come back, and I can still guide/handhold them through the dapp depending if their tx is "pending" (show waiting prompt) or "confirmed" (alert and take them to the proper page). I'm sure this is how BlockNative does this.
I guess this would be more of a limited feature set, since it's just a matter of making it easier for the dapp dev to subscribe to a specific tx, and adding callbacks.