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

Transaction handling #79

Open
jodator opened this issue Oct 28, 2021 · 0 comments
Open

Transaction handling #79

jodator opened this issue Oct 28, 2021 · 0 comments

Comments

@jodator
Copy link

jodator commented Oct 28, 2021

I gather my remarks on the transaction handling that we had in Pioneer and what we could do better.

First of all, our hook is too tied to the code used for modal creations so it is not worth porting 1:1.

From the UI perspective we needed:

  • handling transaction fee before gathering user input (we have useTransactionFee() checks that). Again, I don't see that's needed in a general library
  • automatic way of displaying transaction states (this was done using xstate because of the flows that were using machines anyway)
  • only extension signing (no built-in accounts)

What I see that's needed is this:

  • a simpler status (just a type returned from hook)
  • signing with multiple types of accounts requires different handling AFAIR and checking keyring if the account is injected or not. But the API might be simple. See this change of removing dev accounts)
const transaction = api.tx.balances.transfer(...)
const {sign} = useTransaction(transacion)
const signingAddress: AccountId = '0x...'

<Button onClick={() => sign(address)} />
  • Usually, there's a need to display the transaction fee (using paymentInfo) - but that requires signing address AFAIR. So the signer account might be passed to hook as well.
  • Usually, we want to get some information out of the events → recently I found getDataFromEvent() with proper types quite helpful
  • The batch transactions might fail but some of the transactions in the batch will pass → harder to set status PASS / FAIL
  • Transaction result will be queryable after 'inBlock' (confirmation comes a bit later 'finalized')
  • It would be worth investigating if using promise instead of observable could result in more readable code
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

No branches or pull requests

1 participant