Wallet native logic

[abefernan]

Closes #7

[ethanfrey]

Improve error handling on sendTokens result, but sendTokens seems to throw no error.

Check if the result has a code. Code 0 or undefined is success. Other code is an error (use log)

  public async postTx(tx: StdTx): Promise<PostTxResult> {
    const result = await this.lcdClient.postTx(tx);
    if (!result.txhash.match(/^([0-9A-F][0-9A-F])+$/)) {
      throw new Error("Received ill-formatted txhash. Must be non-empty upper-case hex");
    }

    return result.code !== undefined
      ? {
          height: Uint53.fromString(result.height).toNumber(),
          transactionHash: result.txhash,
          code: result.code,
          rawLog: result.raw_log || "",
        }
      : {
          logs: result.logs ? parseLogs(result.logs) : [],
          rawLog: result.raw_log || "",
          transactionHash: result.txhash,
          data: result.data ? fromHex(result.data) : undefined,
        };
  }

[ethanfrey]

Example how to check for errors:

try {
  const res = await client.sendTokens(rcpt, [{denom: "ushell", amount: "123456"}]);
  if (res.code) {
    throw new Error(`sendToken error: ${res.log}`);
  }
  // handle success case
} catch (e) {
  // handle error case
}

You can do more introspection with the result when res.code is truthy to build clearer error messages

[ethanfrey]

Reviewed the UI by clicking around. And actually had a hard time to get send to error... validation logic and all.

Places to improve:

• Rather than 79000 ushell, please show 0.079SHELL. For the mapping, just define some mapping in the config. Please look at BankMeta in faucet for an example of this metadata. Here is how they build a Decimal using the balance and the metadata

• On the Send page, it is very helpful to show the current balance, so I can remember what I have available to send.

I do actually get a "nice" error message now: "Send transaction failed:insufficient funds: insufficient account funds; 72994ushell < 74000ushell: failed to execute message"

I will take a look at the code, but the flow is working pretty well. Mainly changing ushell to SHELL. (And don't forget to do the ureef -> REEF mapping as well)

[ethanfrey]

Also, tried search. It doesn't change anything. I tried the following accounts (which both exist on coralnet):

• coral1r4tnas9cyfjvsq5yuusrlmvzxr6h7wu9srjxfd
• coral17qgdxytgygz54etpq4nkmptfl5c3rl8z3sfxxa

Please check the search field

[ethanfrey]

Looks good besides my comments

[ethanfrey]

Why all optional? Does this make sense if it misses httpUrl or such fields?

[abefernan]

I'd need to know which ones can be optional, I just needed codeId to be optional at the moment

[ethanfrey]

Stuff that can move to design in a future PR, right?

[abefernan]

I would move ProtectedSwitch to logic, since it does not have to do with layout or styling

[ethanfrey]

Check for if (result.code) { here. We can definitely not rely on the "github.com" error message. Soon we will turn off all the stack trace.

[abefernan]

So the source of my confusion was that result is PostTxResult but it does not give me access to the code field. I see now that I have 2 type guards: isPostTxSuccess and isPostTxFailure, that let me narrow the type. However, I'm guessing that I can just do if (isPostTxFailure(result))

[ethanfrey]

I was looking for where this was used (to see the search logic) and couldn't find it anywhere

[abefernan]

Sorry for wasting your time looking for the logic, I was not 100% sure about the flow and so it was not implemented yet. I had thought about pre-filling the searchbar with your own address and letting you change it to check other addresses' balance, but the flow described in #28 looks much better

[ethanfrey]

Please just fix the logic changes and do not worry about the UI stuff I mentioned above. I made another issue to rethink those flows: #28

I think the Native Token and the CW20 Token designs are more different than I thought. And you made some good points when we talked.

[ethanfrey]

Propose some improvements to the coin map logic

[ethanfrey]

I see what you do here, and in the config and it seems to work.
Seems a bit odd going back and forth and back again.

I would just store a map native token -> display token, and always pass the native token (ushell) as arguments internally. Then you can just do the forward mapping for the display.

[ethanfrey]

You can remove a few lines above and below and just use this for the forward mapAmount

[ethanfrey]

I would keep ushell and ureef and remove the other two. Going back and forth risks loosing precision.
(In fact if this ever ends up as a number, this is only safe if we have positive fractionalDigits)