soroban-example-dapp: add support for fees
Closed this issue · 2 comments
@tsachiherman , I think the changes for simulation data on js-soroban-client #77 are shaping up to be backwards compatible with the current dapp, as dapp submits tx with classic fee(via soroban-react lib) to soroban-client::prepareTransaction which hasn't had an interface change, under the hood it applies the new SorobanTransactionData,Auth, Fees from simulation onto the user's tx. It appends the new fee onto existing classic fee for final tx fee. So, end result would be same UX flow from pledge button to freighter wallet popup display to then updated pledged amounts.
the scope here doesn't mention ux changes, so, if this silent final fee flow is ok then the scope here should be pretty limited to just updating the version ref to js-soroban-client.
we can do additional changes to show new UX activity like a user dialog popup with a confirm for the fees, but that could be addressed in a post-release feature if you agree.
@tsachiherman , I think the changes for simulation data on js-soroban-client #77 are shaping up to be backwards compatible with the current dapp, as dapp submits tx with classic fee(via soroban-react lib) to soroban-client::prepareTransaction which hasn't had an interface change, under the hood it applies the new SorobanTransactionData,Auth, Fees from simulation onto the user's tx. It appends the new fee onto existing classic fee for final tx fee. So, end result would be same UX flow from pledge button to freighter wallet popup display to then updated pledged amounts.
the scope here doesn't mention ux changes, so, if this silent final fee flow is ok then the scope here should be pretty limited to just updating the version ref to js-soroban-client.
we can do additional changes to show new UX activity like a user dialog popup with a confirm for the fees, but that could be addressed in a post-release feature if you agree.
It's ok that we don't add any UI to iterate not the fees selection, but we still need to add a in-code comment where that functionality would be implemented.
Also, this is the first place where we can actually test that these calculated fees truly work.. so we shouldn't close this ticket before validating the end-to-end functionality.