SmartTokenLabs / TokenScript

TokenScript schema, specs and paper
http://tokenscript.org
MIT License
242 stars 71 forks source link

A template language for `item-view` #325

Open SmartLayer opened 4 years ago

SmartLayer commented 4 years ago

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:

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:


† 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


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 commented 4 years ago

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.