We and external developers have reusable UI components that are tested and dependable

[katelynsills]

We have a few react UI components that we should reuse in our dapps and suggest to external dapp developers. We should make a package in agoric-sdk which has these components. They are (names below are tentative):

Basic Components:

• NatAmountInput - a MaterialUI TextField Input for inputting nats
• NatPurseListItemDetailed - a MaterialUI ListItem that shows the purse petname as the primary text, with the brand petname and the purse balance as secondary text. Only works for nats.
• PurseSelector - a MaterialUI TextField Select. A parent of PurseListItemDetailed or similar. Used for selecting purses from a list.
• Non-nat versions of the above
• decimalPlaces handling for Ratios

Larger Components:

• Swap - select the purses in/out and enter the amounts. Probably should be changed to select brands first.

Libraries:

• display - takes a raw Nat value and uses the decimalPlaces in displayInfo to display it properly. Also parses, doing the reverse.

Tests

Unit tests for each component and library should be created. The tests should use AVA and enzyme.

This package in agoric-sdk should be usable by dapp-token-economy.

[zarutian]

Adding or augmenting that list:

• Collapseable list for MathKind.STRING_SET amounts
• Such a list but with selection mechanism (checkboxes?) for withdrawal from such a purse.

And the question is how would or should MathKind.SET items be displayed?

Should be there some standardized properties in brands displayInfo record for these purposes?

(self-note: So I do not forget, what about for the RECT_AREAS? That would look something like a canvas with filled rectangles each with their size written in the center in UUxUU format and coordnates in upper left corner in (U, U) format)

[katelynsills]

For complex MathKind.SET values, we will need to use the user's petnames to display the presences that may exist.

[katelynsills]

More needs to be done here, but I'm taking this out of the Beta Treasury milestone because it's a long term process. For instance, instead of just enzyme which cannot test the UI as rendered, we really need a way to test user input.