Page MenuHomePhabricator

[Cashtab] Allow typed input for agora quantity selection
ClosedPublic

Authored by bytesofman on Tue, Dec 31, 00:13.

Details

Summary

OrderBook was originally built with a slider that only allowed selection of the discrete values allowed by Agora. This ended up being bad UX. Almost impossible to select an amount even close to what you want.

Replace with typed input. The tradeoff is that we must validate this input and also present the user the delta (if any) between what was input and what is the closest thing we can use.

imo this is better UX though. We had many users complain about the slider.

Test Plan

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Correct bad comments, add better comments in useEffect for when takeTokenQtyDecimalized is set

bytesofman added inline comments.
cashtab/src/components/Agora/OrderBook/index.tsx
689 ↗(On Diff #51862)

refactor what happens when the user input qty changes

before, this amount was "prevalidated" since the slider was only allowed to choose valid amounts

Now, we validate it every time

783 ↗(On Diff #51862)

we build a better confirmation modal that shows the delta, if any, from user input

image.png (450×310 px, 65 KB)

cashtab/src/validation/index.ts
1221 ↗(On Diff #51862)

we must refactor our input validation function now that we take in decimalized quantities for the user

we must validate the input for correct decimals and type

before, the slider took care of this validation

emack requested changes to this revision.Tue, Dec 31, 01:49
emack added a subscriber: emack.
emack added inline comments.
cashtab/src/components/Agora/OrderBook/index.tsx
269 ↗(On Diff #51862)

Worth a toast.error otherwise the user might be clicking away thinking Cashtab isn't registering their mouse click.

407–415 ↗(On Diff #51862)

this specific segment is worth a unit test for. I know it's specifically used here for now but this function influences users spending XEC, so the risk impact is higher.

422 ↗(On Diff #51862)
This revision now requires changes to proceed.Tue, Dec 31, 01:49
bytesofman added inline comments.
cashtab/src/components/Agora/OrderBook/index.tsx
269 ↗(On Diff #51862)

in this case, it really should never happen. we could throw a toast in there. but this is really just a courtesy loop to keep typescript satisfied. Since this happens often, I think the best practice is to comment. It seems safer to throw a toast, but then we get in a situation where we are throwing a toast or some kind of log in 100s of these, and it is not that useful.

407–415 ↗(On Diff #51862)

ugh good point. such a pain in the ass to make these agora mocks but really do need to do it.

the main issue is that the mocks currently in there are "too good" i.e. the resolution is such that all quantities are possible.

...well prob not ALL quantities....I'll find a way to get this with existing mocks or add a new mock. We do need to have this tested.

422 ↗(On Diff #51862)

it's the token qty here

we could throw in a ticker -- but some tokens do not have a ticker
and I think the name is too long

imo having the token icon and showing all the quantities is clear enough. adding the token info does not clear it up much.

The fields that are price related are both labeled as such, with XEC or with fiat ticker.

bytesofman marked 3 inline comments as done.

add new mock and test case to confirm rendering of delta from input and actual

back out unrelated line break removal

Is there a guarantee that the selected buy amount is <= to the user requested amount ?

cashtab/src/components/Agora/OrderBook/index.tsx
465 ↗(On Diff #51865)

While you're at it

Is there a guarantee that the selected buy amount is <= to the user requested amount ?

Here's the function in question

https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/modules/ecash-agora/src/partial.ts#L597

/**
* Prepare the given acceptedTokens amount for the Script; `acceptedTokens`
* must have the lowest numTokenTruncBytes bytes set to 0 and this function
* does this for us.
**/
public prepareAcceptedTokens(acceptedTokens: bigint): bigint {
        const numTokenTruncBits = BigInt(8 * this.numTokenTruncBytes);
        return (acceptedTokens >> numTokenTruncBits) << numTokenTruncBits;
}

I hadn't looked into it before, but looks like yes -- given an input acceptedTokens this function can only return a value <= acceptedTokens

So, gives me some more confidence about this UX approach. When I made this diff I didn't look into this, just figured the delta was an acceptable trade-off to the UX of selecting, as long as the user can see the delta before buying.

bytesofman added inline comments.
cashtab/src/components/Agora/OrderBook/index.tsx
465 ↗(On Diff #51865)

nice, patched

bytesofman marked an inline comment as done.

typo fix, make sure you display the actual amount bought in the buy success notification

locale decimalized format in the notification

This revision is now accepted and ready to land.Tue, Dec 31, 23:44