{"id":13860,"date":"2023-03-25T14:57:47","date_gmt":"2023-03-25T19:57:47","guid":{"rendered":"https:\/\/rud.is\/b\/?p=13860"},"modified":"2023-03-25T14:57:47","modified_gmt":"2023-03-25T19:57:47","slug":"linking-lits-lightweight-web-components-and-webr-for-vanilla-js-reactivity","status":"publish","type":"post","link":"https:\/\/rud.is\/b\/2023\/03\/25\/linking-lits-lightweight-web-components-and-webr-for-vanilla-js-reactivity\/","title":{"rendered":"Linking Lit’s Lightweight Web Components And WebR For Vanilla JS Reactivity"},"content":{"rendered":"

\n See it live<\/a> before reading!\n<\/p><\/blockquote>\n

This is a Lit + WebR reproduction of the OG Shiny Demo App<\/a><\/p>\n

Lit<\/a> is a javascript library that makes it a bit easier to work with Web Components<\/a>, and is especially well-suited in reactive environments.<\/p>\n

My recent hack-y WebR experiments have been using Reef<\/a> which is an even ligher<\/em>-weight javascript web components-esque library, and it’s a bit more (initially) accessible than Lit. Lit’s focus on “Web Components-first” means that you are kind of forced into a structure, which is good, since reactive things can explode if not managed well.<\/p>\n

I also think this might Shiny folks feel a bit more at home.<\/p>\n

This is the structure of our Lit + WebR example (I keep rejiggering this layout, which likely frustrates alot of folks<\/em> ?)_<\/p>\n

lit-webr\n\u251c\u2500\u2500 css\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 style.css             # you know what this is\n\u251c\u2500\u2500 favicon.ico               # when developing locally I want my icon\n\u251c\u2500\u2500 index.html                # you know what this is\n\u251c\u2500\u2500 main.js                   # the core experiment runner\n\u251c\u2500\u2500 md\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.md               # the core experiment markdown file\n\u251c\u2500\u2500 r-code\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 region-plot.R         # we keep longer bits of R code in source files here\n\u251c\u2500\u2500 r.js                      # place for WebR work\n\u251c\u2500\u2500 renderers.js              # these experiment templates always use markdown\n\u251c\u2500\u2500 themes\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 ayu-dark.json         # my fav shiki theme\n\u251c\u2500\u2500 utils.js                  # handy utilities (still pretty bare)\n\u251c\u2500\u2500 wc\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 region-plot.js        # ?? WEB COMPONENT for the plot\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 select-list.js        # ??               for the regions popup menu\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 status-message.js     # ??               for the status message\n\u251c\u2500\u2500 webr-serviceworker.js.map # not rly necessary; just for clean DevTools console\n\u2514\u2500\u2500 webr-worker.js.map        # \u261d?\n<\/code><\/pre>\n
A great deal has changed (due to using Lit) since the last time you saw one of these experiments. You should scan through the source<\/a> before continuing.<\/p>\n
The core changes to index.html<\/code> are just us registering our web components:<\/p>\n
<script type=\"module\" src=\".\/wc\/select-list.js\"><\/script>\n<script type=\"module\" src=\".\/wc\/region-plot.js\"><\/script>\n<script type=\"module\" src=\".\/wc\/status-message.js\"><\/script>\n<\/code><\/pre>\n
We could<\/em> have rolled them up into one JS file and minified them, but we’re keeping things simple for these experiments.<\/p>\n
Web Components (“components” from now on) become an “equal citizen” in terms of HTMLElements<\/code>, and they’re registered right in the DOM.<\/p>\n
The next big change is in this file (the rendered main.md<\/code>), where we use these new components instead of our <div><\/code>s. The whittled down version of it is essentially:<\/p>\n
<status-message id=\"status\"><\/status-message>\n\n<region-plot id=\"regionsOutput\" svgId=\"lit-regions\">\n  <select-list label=\"Select a region:\" id=\"regionsInput\"><\/select-list>\n<\/region-plot>\n<\/code><\/pre>\n
The intent<\/em> of those elements is pretty clear (much clearer than the <div><\/code> versions), which is one aspect of components I like quite a bit.<\/p>\n
You’ll also notice components are -<\/code> (dash) crazy. That’s part of the Web Components spec and is mandatory.<\/p>\n
We’re using pretty focused components. What I mean by that is that they’re not very reusable across other projects without copy\/paste. Part of that is on me since I don’t do web stuff for a living. Part of it was also to make it easier to show how to use them with WebR.<\/p>\n
With more modular code, plus separating out giant chunks of R source means that we can actually put the entirety of main.js<\/code> right here (I’ve removed all the annotations; please look at main.js<\/code> to see them; we will be explaining one thing in depth here, vs there, tho.)<\/em>:<\/p>\n
import { renderMarkdownInBody } from \".\/renderers.js\";\nimport * as d3 from \"https:\/\/cdn.jsdelivr.net\/npm\/d3@7\/+esm\";\n\nawait renderMarkdownInBody(\n  `main`,\n  \"ayu-dark\",\n  [ 'javascript', 'r', 'json', 'md', 'xml', 'console' ],\n  false\n)\n\nlet message = document.getElementById(\"status\");\nmessage.text = \"WebR Loading\u2026\"\n\nimport * as R from \".\/r.js\";\n\nmessage.text = \"Web R Initialized!\"\n\nawait R.webR.installPackages([ \"svglite\" ])\n\nawait R.library(`svglite`)\nawait R.library(`datasets`)\n\nconst regionRender = await globalThis.webR.evalR(await d3.text(\"r-code\/region-plot.R\"))\n\nmessage.text = \"{svglite} installed\"\n\nconst regions = document.getElementById(\"regionsInput\")\nconst plotOutput = document.getElementById(\"regionsOutput\")\n\nregions.options = await (await R.webR.evalR(`colnames(WorldPhones)`)).toArray()\nplotOutput.region = regions.options[ 0 ]\nplotOutput.renderFunction = regionRender\nplotOutput.render()\n\nmessage.text = \"Ready\"\n<\/code><\/pre>\n
I want to talk a bit about this line from main.js<\/code>:<\/p>\n
const regionRender = await globalThis.webR.evalR(\n  await d3.text(\"r-code\/region-plot.R\")\n)\n<\/code><\/pre>\n
That fetches the source of the single R file we have in this app, evaluates it, and returns the evaluated value (which is an R function<\/code> object) to javascript. This is the script:<\/p>\n
renderRegions <- function(region, id = \"region-plot\") {\n\n  # our base plot theme\n\n  list(\n    panel.fill = \"#001e38\",\n    bar.fill = \"#4a6d88\",\n    axis.color = \"#c6cdd7\",\n    label.color = \"#c6cdd7\",\n    subtitle.color = \"#c6cdd7\",\n    title.color = \"#c6cdd7\",\n    ticks.color = \"#c6cdd7\",\n    axis.color = \"#c6cdd7\"\n  ) -> theme\n\n  # get our svg graphics device amp'd\n  s <- svgstring(width = 8, height = 4, pointsize = 8, id = id, standalone = FALSE)\n\n  # setup theme stuff we can't do in barplot()\n  par(\n    bg = theme$panel.fill,\n    fg = theme$label.color\n  )\n\n  # um, it's a barplot\n  barplot(\n    WorldPhones[, region],\n    main = region,\n    col = theme$bar.fill,\n    sub = \"Data from AT&T (1961) The World's Telephones\",\n    ylab = \"Number of Telephones (K)\",\n    xlab = \"Year\",\n    border = NA,\n    col.axis = theme$axis.color,\n    col.lab = theme$label.color,\n    col.sub = theme$subtitle.color,\n    col.main = theme$title.color\n  )\n\n  dev.off()\n\n  # get the stringified SVG\n  plot_svg <- s()\n\n  # make it responsive\n  plot_svg <- sub(\"width='\\\\d+(\\\\.\\\\d+)?pt'\", \"width='100%'\", plot_svg)\n  plot_svg <- sub(\"height='\\\\d+(\\\\.\\\\d+)?pt'\", \"\", plot_svg)\n\n  # return it\n  plot_svg\n\n}\n<\/code><\/pre>\n
That R function is callable right from javascript<\/em>. Creating that ability was super brilliant of George (the Godfather of WebR). We actually end up giving it to the component that plots the barplot (see region-plot.js<\/code>) right here:<\/p>\n
plotOutput.renderFunction = regionRender\n<\/code><\/pre>\n
We’re getting a bit ahead of ourselves, since we haven’t talked about the components yet. We’ll do so, starting with the easiest one to grok, which is in status-message.js<\/code> and is represented by the <status-message><\/status-message><\/code> tag.<\/p>\n
These custom Lit components get everything HTMLElement<\/code> has, plus whatever else you provide. I’m not going to show the entire source for status-message.js<\/code> here as it is (lightly) annotated. We’ll just cover the fundamentals, as Lit components also have alot going on and we’re just using a fraction of what they can do. Here’s the outline of what’s in our status-message<\/code>:<\/p>\n
export class StatusMessage extends LitElement {\n  static properties = { \/* things you can assign to and read from *\/ }\n  static styles = [ \/* component-scoped CSS *\/ ]\n  constructor() { \/* initialization bits *\/\n  render() { \/* what gets called when things change *\/ }\n}\n\/\/ register it\ncustomElements.define('status-message', StatusMessage);\n<\/code><\/pre>\n
Our status-message<\/code> properties<\/code> just has one property:<\/p>\n
static properties = {\n  text: {type: String}, \/\/ TypeScript annotations are requried by Lit\n};\n<\/code><\/pre>\n
This means when we do:<\/p>\n
let message = document.getElementById(\"status\");\nmessage.text = \"WebR Loading\u2026\"\n<\/code><\/pre>\n
we are finding our component in the DOM, then updating the property we defined. That will trigger render()<\/code> each time, and use any component-restricted CSS we’ve setup.<\/p>\n
Things get a tad more complicated<\/em> in select-list.js<\/code>. We’ll just cover the highlights, starting with the properties<\/code>:<\/p>\n
static properties = {\n  id: { type: String },    \/\/ gives us easy access to the id we set\n  label: { type: String }, \/\/ lets us define the label up front\n  options: { type: Array } \/\/ where the options for the popup will go\n};\n<\/code><\/pre>\n
If you recall, this is how we used them in the source:<\/p>\n
<region-plot id=\"regionsOutput\" svgId=\"lit-regions\">\n  <select-list label=\"Select a region:\" id=\"regionsInput\"><\/select-list>\n<\/region-plot>\n<\/code><\/pre>\n
The id<\/code> and label<\/code> properties will be available right away after the custom element creation.<\/p>\n
We start option<\/code> with an empty list:<\/p>\n
constructor() {\n  super()\n  this.options = []\n}\n<\/code><\/pre>\n
Our render()<\/code> function places the <label><\/code> and <select><\/code> tags in the DOM and will eventually populate the menu once it has data:<\/p>\n
render() {\n  const selectId = `select-list-${this.id}`;\n  return html`\n  <label for=\"${selectId}\">${this.label} \n    <select id=\"${selectId}\" @change=${this._dispatch}>\n      ${this.options.map(option => html`<option>${option}<\/option>`)}\n    <\/select>\n  <\/label>\n  `;\n}\n<\/code><\/pre>\n
Their clever use of JS template strings makes it much easier than ugly string concatenation.<\/p>\n
\n  That html<\/code> in the return<\/code> is doing alot<\/em> of work, and not just returning text. You gotta read up on Lit to get more info b\/c this is already too long.\n<\/p><\/blockquote>\n
The way we wired up reactivity in my Reef examples felt kludgy, and even the nicer way to do it in Reef feels kludgy to me. It’s really<\/em> nice in Lit. This little addition to the <select><\/code> tag:<\/p>\n
@change=${this._dispatch}\n<\/code><\/pre>\n
says to call a function named _dispatch<\/code> whenever the value changes. That’s in the component as well:<\/p>\n
_dispatch(e) {\n  const options = {\n    detail: e.target,\n    bubbles: true,\n    composed: true,\n  };\n  this.dispatchEvent(new CustomEvent(`regionChanged`, options));\n}\n<\/code><\/pre>\n
We setup a data structure and then fire off a custom event that our plot component will listen for.  We’ve just linked them together on one side. Now we just need to populate the options<\/code> list, using some data from R:<\/p>\n
const regions = document.getElementById(\"regionsInput\")\nregions.options = await (await R.webR.evalR(`colnames(WorldPhones)`)).toArray()\n<\/code><\/pre>\n
That’ll make the menu appear.<\/p>\n
Hearkening back to the main.js<\/code> plot setup:<\/p>\n
const plotOutput = document.getElementById(\"regionsOutput\")\nplotOutput.region = regions.options[ 0 ]\nplotOutput.renderFunction = regionRender\nplotOutput.render()\n<\/code><\/pre>\n
we see that we:<\/p>\n