Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(gui): Swap state stepper to use Tauri events #77

Merged
merged 13 commits into from
Sep 22, 2024

Conversation

binarybaron
Copy link

@binarybaron binarybaron commented Sep 11, 2024

Previously we used the data we fetched via the rpc (GetSwapInfo call, saved in redux in rpc.swapInfos) to decide what to display in the state stepper to the user. The state stepper is displayed at the bottom of the SwapDialog.

However, we are moving away from our depedence on periodic rpc calls and towards relying more and more on the events we receive from the Host (from Tauri). Our goal is to rely solely on the Tauri events for everything displayed about the currently running swap.

This PR includes the following changes:

  • refactor the SwapStateStepper such that it relies only on the Tauri events
  • emit two new Tauri events (EncryptedSignatureSent, CancelTimelockExpired) in the state machine
  • correctly emit BtcRefunded Tauri event after Bitcoin refund transaction is published
  • differentiate between "Waiting for them to redeem the Bitcoin" and "Revealing encrypted signature to the other party" on the SwapStatePage (content displayed in the center of the SwapDialog)

@binarybaron
Copy link
Author

binarybaron commented Sep 12, 2024

We should use this opportunity to re-think the state stepper design. Currently there are a few open questions.

Types of steppers

We have two different stepper paths (Happy, Unhappy). Each step in a stepper can be either

  1. Pending
  2. Not yet reached
  3. Failed
  4. Done

Screenshot 2024-09-20 at 15 51 39

Screenshot 2024-09-20 at 16 05 55

Screenshot 2024-09-20 at 16 06 46

Open questions

  1. Should we display the first "Locking your Bitcoin" step as done (with a checkmark) even if the lock transaction has not received a confirmation yet? It could be that the transaction never gets confirmed. Display it as done could be misleading.
  2. Should we merge both the "attempting to refund Bitcoin" and "attempting to cooperatively redeem Monero after punish" steps into one? Currently we have them merged into one step "Attempting recovery". Are there better way to visualize this to the user? One I can think of would be Cancelling swap -> Attempting Bitcoin refund -> Attempting cooperative Monero redeem. If the refund fails due to the timelock having expired the "Attempting Bitcoin refund" step is marked as failed and the "Attempting cooperative Monero redeem" is displayed as pending.
  3. In the case of a "cooperative redeem" the stepper can be confusing. It first displays the "Attempting recovery" as pending and if successful switches to the other stepper indicating the swap went normal ("Redeeming your Monero" is marked as done)

@Einliterflasche What do you think?

@binarybaron binarybaron changed the title refactor(gui): Rework swap state stepper to use Tauri events refactor(gui): Swap state stepper to use Tauri events Sep 20, 2024
@binarybaron
Copy link
Author

I'm merging this. #77 (comment) should be made in another issue.

@binarybaron binarybaron merged commit 97510a8 into master Sep 22, 2024
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant