This meeting is about the views of cards.
There are two types of views: item-view and view. Each card can have an item-view and a view.
<cards> <token> <item-view>...</item-view> <view>...</view> </token> <activity> <item-view>...</item-view> <view>...</view> </activity> <action> <item-view>...</item-view> <view>...</view> </action> </cards>
Sunil produced an illustration with two example tokens with different item-views, denoted by ➀ and ➁:
Observe that ➀ is a typical payment token which only has 1 important value: the amount. ➁ is a bit more complicated since points expire. The expiration date is under highlight. What he didn't illustrate are non-payment-tokens. e.g. a car ownership token might have 1 or 2 keys produced, or is being rented to someone else hence not under the control of the original owner. A crypto-kitty, however, might be pregnant or sick. You can imagine these are going to have a bit different content in the view. You get the idea with a bit of imagination.
item-view are in one list, it can be expensive to maintain a lot of web-views. It is clearly impossible to maintain a list of web-views each with its own reactJS components, but it may also be a bad user experience even if we implement a lot of web-views without using reactJS components (that is, the view is regenerated when marked dirty, instead of updated).
Having the implementation dictating the design is a bit tail wagging the dog, but we have to put implementation restraint in mind. There are a few approaches for implementations in the context of mobile wallet:
setIntervalor display an input box. Each view is rendered in a webview, and it's in-memory DOM tree parsed for static HTML.
- Use a cached image. I wouldn't recommend this unless with quite a noticeable user experience difference, since 𝑎) static HTML still needs to be generated for the search to work; 𝑏) result isn't responsive (e.g. when a user rotates the screen).
- Hardcode ERC20 views with native components, since they are mostly similar, and take either 0 or 1 approach for other views.
The last combined approach needs a bit of elaboration.
Case 1. Standard ERC20 tokens
Let's first assume all ERC20 tokens look like Suni's illustrated ➀, in which case the TokenScript author doesn't need to define an
<item-view> in the
Therefore, the ERC20 tokens can be rendered in a mobile wallet with native widgets. No cached HTML is needed since we also know what search keys match these tokens (token name, symbol and balance).
This is achieved by having a default ERC20 TokenScript released by tokenscript.org and shipped by user-agents like αWallet. In that default ERC20 TokenScript, the
Case 2. ERC20 tokens with customisation
Then, let's look at ERC20 tokoens with customisation, like Suni's illustrated ➁. The TokenScript author takes the default ERC20 TokenScript, modify its
<item-view>, in this case adding expiry, and includes it in the TokenScript he releases.
<item-view> being defined, mobile wallet like αWallet, the wallet renders the
<item-view> with a WebView.
Case 3. Non-ERC20 or SmartTokens
Finally, the SmartTokens - like Car Ownership Toke, which Sunil did not illustrate - can have their own
<item-view> from scratch.
- The implementation is transparent to the TokenScript authors. TokenScript authors do not need to learn that wallets render default ERC20 tokens hard-coded to look like that they are generated from the default ERC20 TokenScript's
<item-view>. They are introduced to
<item-view>only when they need to customise it.
- The implementation does not forbid the authors to use
setInterval(). In Sunil's ➁, the TokenScript author might wish to replace the expiry date with something like "Expiring in 1 days" or "Expiring in 1 hours" which depends on
- The implementation doesn't block the furture use of solution 1.
One approach is to restrict the
<item-view> into a message. A wiki-like style can be implemented to allow expression of fields, values and translation.
My (Weiwu)'s objection is that, first, it's not supportive of web3 use-cases. e.g. One might wish to display a car photo with a certain layout, in the case of car-ownership token. (Observe Car-Next-Door example). Second, it adds one concept TokenScript authors needs to master which doesn't have a reuse case (e.g. in the
The counter-argument for my object in the meeting was that you can use the message-approach for wallet context and when we properly support web3 context we can use a proper view. My argument against that "migration path" is there is unnecessary baggage to carry to web3. Either web3 engine still have to learn to implement messages in case the author chose that implementation for web3, or the authors have to remember that message implementation isn't possible for web3 context, adding to the number of different views they have to maintain. The increase of "you can, but ...." scenarios hurts adoption.
But there are some merits of this approach, to restrict the
<item-view> into a message. One is that it does away the performance issue completely, now and the future. The other advantage is that implementing different tenses ("you are about to receive an either" and "you received an ether") is easier with a message than with view, and that situation rises when you apply
<item-view> to activities.
My general feedback on that is 𝑎) that restriction hurts web3 innovations too much; 𝑏) if only used for activites', but not tokens'
<item-view>, it has less damage to web3 use-cases, but more special cases ("Yes you can, but ...") for authors. As of the tense problem, there is still might be room to fix that during the design for notifications (another piece of ongoing work).