Open SmartLayer opened 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.
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:item-view
convert it to static HTML.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:
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
Since javascript/wasm is distinguished with
type
:vs