A template language for `item-view`

[SmartLayer]

trafficstars

Currently, we load React library in token cards and we do the same for item-view.

I argue that a item-view does not require much interaction and can be pre-rendered and indexed. Effectively I mean the following:

• For every item-view convert it to static HTML.
• Store the content of that HTML in an indexed database.
• Update the static HTML if needed.

This can be done on-demand. Let's say the user scrolls over the tokens he has in his wallet and most of them only static HTML item-view are shown. if a user scrolls down further in the Wallet tab, and a token appears, which, according to the attributes used in the view and the event that might affect these attributes, needs updating. We can update that token by rendering that one (i.e. not using static HTML) but in the meanwhile, every other token uses static HTML.

The same for events, since an event, may change. e.g. voting deadline postponed as the admin user sent a transaction to force the DAO contract to update the deadline, or during a reörg, a voting event has changed from success to failure or failure to success.

The advantage, of course, is that this makes wallet and event tab very fast and searchable. You can further speed up by having a cached version in static HTML and a cached version in JPEG‡

Now, speaking of template langauge:

• Spring framework has a simple template langauge, but we can't use it because they only have a Java based engine.
• XML has XSLT transformation, which is implemented in every language but lack developer base and @hboon borrowed from his experience that its development is painful.
• JSX is a modern and neat language however to render it you need to access dom, which isn't avaiable outside WebView. There are smart tricks to work around this limitation†.
• We already use Make style value reference, like filter="owner=$(owner_address)", so let's continue to use Make style value reference as a template language, forego the looping and conditional stuff a real template engine supports.

---

† Workarounds to use JSX as a template language

To work around the limitation that JSX can't convert a template into static HTML without a WebView, we could render item-view in the old way for the 1st time, capture the in-memory DOM tree and save it as static HTML for later use.

The disadvantage is that the content isn't indexed until you see it, which breaks e.g. search in Activities.

We can't just replace search with a server-side search because offline search (of tokens and activities) are expected. But that's not the end of the path yet. As long as we have Activities (including captured relevant Ethereum events) locally, when a user searches into them, we can try to match the search key with the event's dataObject and the event's JSX code. If the former matches, render that event into an Activity in the search result (if not cached); If the latter matches, render every Activity which uses that JSX code on the fly (if not cached)

---

‡ Should we cache JPEG or static HTML?

Once we obtained the static HTML for an item-view, we must index it in a database, then we can discard the HTML and cache the JPEG version instead.

The advantage is speed. The disadvantage is

• staticlly cached HTML already doesn't have live JavaScript that can update the dom tree, for example doing animation like displaying a count-down or flash if you are near the deadline and haven't acted. However, the TokenScript authore can still work around it by including such in resources (GIF or SVG). Caching the JPEG would kill that workaround.

• when you search into Activities, you might want to highlight the search keyword by inserting <strong> around the keyword in the dom tree; you can't do this with JPEG.

---

P.S. To specify JSX one might use this syntax

<item-view xml:lang="en" type="text/javascript" dialect="JSX">

Since javascript/wasm is distinguished with type:

<view xml:lang="en" type="text/javascript">

vs

<view xml:lang="en" type="application/wasm">

[hboon]

Regarding JSX, from https://github.com/facebook/jsx:

JSX is an XML-like syntax extension to ECMAScript without any defined semantics. It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.