Add new vdom pkg, a rework of virtualdom that includes support for creating Lumino virtual elements using JSX

[telamonian]

When we switched from Phosphor => Lumino, one of the PRs that was left open was for adding a new vdom package. The basic idea is that vdom is meant to be the virtual dom package for Lumino 2.0; the current virtualdom pkg will be deprecated, and all of the renderers for the builtin widgets will switch over to using constructs from vdom instead. The killer feature for vdom is that it adds support for creating Lumino virtual nodes using JSX, and the more declarative paradigm that comes with it.

[telamonian]

Originally posted by @sccolbert in phosphorjs/phosphor#447 (comment)

This is a rewrite of the existing virtualdom package, to be compatible with JSX/TSX. The JSX typings are assembled from Preact (mostly) and React (some), with some custom tweaks as needed.

The typings right now are good, but it assumes every HTML element has all attributes available. We can improve this in the future.

The typings support SVG, but I'm 99% sure it's not going to work yet. I'm sure I'll need to add some code to handle SVG elements properly.

It supports intrinsic elements and now also function components. I still don't think we need support for class-based components, since we already have widgets with their own life-cycle paradigm. The purpose of this package is to provide a tool for easily rendering leaf content out-of-the-box with Phosphor.

This code is fast. On my machine, the included example takes just 15us to render updates.

For Phosphor 2.0, my plan is to deprecate the virtualdom package and replace it with this. For core widgets which make use of custom renderers, I will make the renderer interface more generic so that users can implement their own renderers using any third party package (React, Vue, lit-html, etc...). The default renderers will use this package.

@blink1073 @afshin @ellisonbg @jasongrout @telamonian

[telamonian]

I think Chris did some really fine work here, and I'd like to get this in at some point in the near future. It seems to be mostly functional, but is going to require at least some work (eg the SVG support debugging that Chris mentioned in his post).

I also want to look into how to fold the work that I've been doing recently on custom renderers for individual vdom nodes (#29, #36, #44) into the vdom pkg in this PR. It seems to be both sensible and reasonably practical, but I need to play around with it some more (I should also probably wait for #44 to get pulled in before iterating on this)

[nmichaud]

@telamonian @blink1073 Is there still interest in incorporating this new vdom package into lumino?

[telamonian]

@nmichaud Yeah, definitely. But keep in mind this will take a lot of work to actually implement in the current @lumino/widgets codebase

[GordonSmith]

As an alternative - it might be worth investigating using native web components, as this opens the door for not just React, but also Angular, Vue etc.
I have an experimental wrapper for the splitter widget here: https://gordonsmith.github.io/hpcc-js-wc/components/splitter.html

[fcollonval]

As an alternative - it might be worth investigating using native web components, as this opens the door for not just React, but also Angular, Vue etc.

I'm definitely 👍 to get Lumino widget converted to web components

I have an experimental wrapper for the splitter widget here: https://gordonsmith.github.io/hpcc-js-wc/components/splitter.html

Thanks for sharing

[afshin]

We should probably close this PR for now and re-open this PR whenever it is active again.

This does raise of the question: what should @lumino/virtualdom be in Lumino 2? If we want to change these APIs, time is short because of the JupyterLab 4 upcoming release.

cc: @telamonian @fcollonval

[fcollonval]

We should probably close this PR for now and re-open this PR whenever it is active again.

Yes I think nothing will happen for Lumino 2.

[afshin]

@telamonian please feel free to pick this up any time you wish, closing the PR for now