Skip to content

TokenScript Views

Hwee-Boon Yar edited this page Dec 23, 2019 · 1 revision

TokenScript Views

TokenScript views (<view> and <view-iconified>) are HTML and JavaScript embedded in TokenScript files. The content are extracted and wrapped with appropriate HTML wrapper tags (<html>, <head> and <body> tags) and rendered in WebKit.

Token data is asynchronously injected into the views using JavaScript when available.

While only a single TokenScript view is rendered at a time, multiple view-iconified can be rendered; for e.g. in a screen displaying token cards for tickets, each ticket (if not bundled) will appear as a row in a list.

Rendering

TokenScript clients attempts to render views with the correct height so that all the content is visible. It does it in several passes:

  1. Render the WebKit view with a fixed height (say, 100)
  2. Wait for the view to finish rendering and capture the height using document.body.scrollHeight and set the WebKit view to that height

Platform (including hardware performance) implementation details may require multiple passes in (2) to get the correct height and caching of the height based on the TokenScript file content (hash?) and optionally token data as the key.

Performance

Since there will be multiple TokenScript <view-iconfied> rendered on the same screen and table/list scrolling performance is important for mobile apps, extra care has to be taken here. Here are a few considerations:

Cache the height of the views

This is the responsibility of the TokenScript client.

Reduce the complexity of the contents of <view-iconified> in TokenScript files

This is much less of a problem for <view>.

Part of the responsibility lies with the TokenScript authors. A simple way to improve performance is with the images used.

Generally SVGs render with worse performance than rasterized images in browsers, including WebKit.

On the other hand, rasterized images are often bigger than their SVG equivalent. Tools such as ImageOptim can help reduce the size of rasterized image files.

So it is worth experimenting with both.

TokenScript client developers might also build tools that can help; e.g to gauge when image files are too big to render efficiently, or when SVGs might not be appropriate once more experimentation is done.

Gotchas

A notable gotcha with writing TokenScript views due to how the height of the WebKit is derived from the rendered view itself: The HTML and CSS must be written so that the view doesn't fill the entire height available. Otherwise, this will end up in an infinite cycle where WebKit view's height will keep growing and the view will keep trying to fill the excess height.

Using the CSS unit vw (hundredths of the viewport width) for expressing height can be handy.