Feature Request: Allow to render to any virtual dom implementation using hyperscript

The point of this feature request is to allow better integration of KaTeX inside virtual dom libraries like : React, Preact, Vue.js, Hast, Inferno, Snabbdom… (many more)

Each of these lib basically support an hyperscript implementation to create their flavour of virtual dom :

• React.createElement
• preact.h
• createElement inside a vue render()
• hastscript
• Inferno.h
• snabbdom/h
• ivi

This feature would be a new method taking an hyperscript implementation like :

/**
 * @param {string} expr - the expression to render
 * @param {object} options - katex rendering options
 * @param {function} h - an hyperscript implementation
 * @return {object} - a (virtual) dom tree
 */
katex.renderToVTree(expr, options, h);

Without this integration, there are many known issues :

• Right now a library like rehype-katex has to render katex nodes to strings and to reparse them to integrate in their virtual dom implementation (HAST).
• Many markdown editors that support KaTeX are unable to render the preview with the minimal amount of DOM modification needed, which usually results in preview content being discarded/recreated at each keystroke in the editor.

[kevinbarabash]

There was a similar request to have buildHTML output HAST, see #800. I think having buildHTML output something that is easily consumable by other tools would be good to have. I don’t think that KaTeX needs to define its own DOM representation. As long as style is an object I think we’re okay. In terms of adding a new representation, that feels like a short term solution. Long term, if we’re outputting some version of HAST we may as well use it internally as well. It’s probably easier adding it as a new additional format first and then migrating to use it internally as a separate PR.

[zipang]

@spontaliku-softaria : thank you for this pertinent remark ! You’re mostly right : there are some importants variations to consider in the implementation of the hyperscript DSL.

Some flavours of hyperscript support the extended (Emmet-like) tagname syntax, like in the following example :

h('#id.class1.class2') 
<=> h('div', { className: 'class1 class2', id: 'id'})

Some of them identify the SVG tags while some other offer a specific hyperscript variant for SVG or support a special namespace attribute :

h('path', {d : 'M 0 0 L 10 10'}) 
<=> svg('path', {d : 'M 0 0 L 10 10'}) 
<=> h('path', {d : 'M 0 0 L 10 10', namespace: 'http://www.w3.org/2000/svg'})

And finally, some implementations allow for a varying signature where arguments are recognized by their type, when not on their expected position :

h('div', 'some text')
<=> h('div', {}, ['some text'])

However, i have found that there is some valid ground for a common form that is accepted by almost every implementations and it is the following one :

h(tagName : String!, properties: Object!, children: [String|hNode]!)

Where

• all three parameters are expected in their respective positions and not null or undefined,
• className and class should be both set as a string property that accepts a space separated list of class names
• namespace="http://www.w3.org/2000/svg" should be added to the properties object to create a SVG node.

It’s not perfect (there are still problems occuring on the attributes of the style property as to whether they should be camelCased or kebab-cased) but it allready gives us a good 80/20 ratio : 20% of efforts for ~ 80% support on every hyperscript library.

Now… that could be the moment to propose a Level 1 and Level 2 specification for hyperscript along with a test suite, and see the implementations converge, but it is another story… 😃