Extension: return transaction hash on send

[CroutonDigital]

At this moment namada-extension does not expose Transfer/Transaction status nor transaction hash after request was made.

It's not possible to build good UI without it, bare minimum would be status (sent successfully or rejected/error) and transaction hash in case of success

[emccorson]

I will look into this properly later, but just to let you know there is the namada-tx-completed event which signals when a transaction has completed. Not sure if it will meet your use case completely though.

[thousandsofthem]

@emccorson any docs on how to catch that namada-tx-completed event? So far found mention of events but not how to subscribe to them

In the @namada/types package, you can import an enum providing the various events you can > subscribe to in your interface.
@import { Events } from "@namada/types";
The currently dispatched events are as follows:
...

https://github.com/anoma/namada-interface/blob/main/specs/browser-extension/integration.md#handling-extension-events

probably this:

import { useEventListener } from "@namada/hooks";
import { Events } from "@namada/types";

useEventListener(Events.TxCompleted, () => {
  // ....
});

[thousandsofthem]

@emccorson looks like events don't work at all. Minimal code to reproduce

  window.addEventListener("namada-account-changed", function(e){
    console.log("namada-account-changed", e);
  });
  window.addEventListener("namada-extension-locked", function(e){
    console.log("namada-extension-locked", e);
  });

[emccorson]

@thousandsofthem Thanks for the report. I think you've uncovered a bug there. #670

[emccorson]

@CroutonDigital Namada transactions have two hashes: a wrapper hash and an inner hash. Do you know offhand which one you need (or both)?

I have the code to send the hash in the event (and to fix the events generally), but I just need to figure out how to get the hash from the transaction.

[CroutonDigital]

@emccorson the one that can be displayed on explorer or anything like that. Something user can interact with. Let's go with both for now and figure out which is better later

[emccorson]

I asked around about this a bit more and I think the one we want is the inner tx hash. The PR is now ready for review so hopefully it will get merged soon 👍 I also think we can add better documentation for the extension events, so I've tracked it here: #672

[emccorson]

I also have in mind that the events approach may not be sufficient for tracking multiple transactions e.g. if you submit two transactions at once, when the event comes back, how will you know which transaction it was that completed? There is another PR #658 that would solve this using promises, but it is not reviewed yet. This problem will need some thought...

[zenodeapp]

I also have in mind that the events approach may not be sufficient for tracking multiple transactions e.g. if you submit two transactions at once, when the event comes back, how will you know which transaction it was that completed? There is another PR #658 that would solve this using promises, but it is not reviewed yet. This problem will need some thought...

Hmm, very true. There has to be an identifier that exists until the transaction has gone through completely (probably tabId could serve this purpose). This would probably mean that the popup should not close itself while the transaction is still taking place (both wrapper and inner). A final screen (like a loading screen) could possibly be a solution. Actually think this would make it more user-friendly if it's feasible.

For the event approach the client has to know upon a wallet interaction which tabId is involved, that way one can listen to this specific tx on the frontend when it actually returns. For the promises approach this wouldn't be necessary. Though, I'm currently thinking about a way that could enable both approaches.

Is there an event that triggers when one intiates a tx and does this return the tabId (or any other identifier that could identify the tx)?