2.0 API

Picodom@2.0.0 is coming to you very soon. The signature of <samp>patch</samp> needs to change, and I need your feedback to get it right.

Closes

• https://github.com/picodom/picodom/issues/80: I don’t understand this issue.
• https://github.com/picodom/picodom/issues/77: I will add new tests.
• https://github.com/picodom/picodom/issues/92: Either one of below proposals will enable you to target a DOM element to be replaced instead of always pre-pending to a container.
• https://github.com/picodom/picodom/issues/89: The “Double Espresso Steamed Soy Milk Foam” proposal below fixes this issue, but I’ll likely proceed with “Bitter Tea” and close that issue as wontfix. There is no way to please everyone.
• https://github.com/picodom/picodom/issues/65: I’ll give a shot at adding types for VDOM events and close there.

Bitter Tea

Bring back the old pre-1.0 signature. This API is more flexible and easier to implement at the expense of a slightly worse developer experience (is it?). The justification is that Picodom is intended to be used to create tiny Hyperapp-like view frameworks instead of directly consumed. Still, this is IMO much better than similar popular alternatives.

import { h, patch } from "picodom"

// First and every other patch.
let element = patch(
  container,
  element,
  oldNode,
  newNode
)

Double Espresso Steamed Soy Milk Foam

This proposal arguably improves the surface API providing at the expense of “slightly” less flexibility. This also has out of the box SSR DOM rehydration. This API makes consuming picodom directly more fun, but a bit awkward to integrate into your own library because you need to be aware there would be essentially two ways to call <samp>patch</samp>, the first time you call it, and every other time.

SSR recycling is enabled by providing a <samp>recycleElement</samp> to patch that works the same way as https://github.com/hyperapp/hyperapp/pull/590.

import { h, patch } from "picodom"

// First patch.
let element = patch(vnode, containerElement)

// or first patch with server side rendered rehydration

let element = patch(vnode, containerElement, recycleElement)

// Every other patch.
patch(vnode, element)

/cc @mindplay-dk @JSteunou @estrattonbailey @pspeter3 @maxholman @dancespiele

[rbiggs]

The more a look at it, the more I like the Double Espresso Steamed Soy Milk Foam proposal. Funny how that just rolls off the tongue. I like the support for SSR too. It basically gives those who want them a mount and a render/update. They can easily write a wrapper function for each. Besides, I’ve never been a big fan of bitter tea. A double espresso, no problem.

[rbiggs]

Just to clarify, the new JSX syntax <></> is not an empty element. It’s just a shorthand convenience for using <React.Fragment></React.Fragment>, which in turn creates a documentFragment. Since documentFragments only exist in memory and are thrown away when they are inserted into the DOM, they don’t have properties. They do have a few attributes, such as childNodes, etc., and methods such as appendChild.

You can’t have a documentFragment that would fire an oncreate since they never get created in the DOM. Same problem with onupdate, etc. In React, lifecycle hooks are defined at the component level, not on the elements, so this isn’t a problem for them.

Introducing support for documentFragment in React was not trivial. It took a lot of work from their team. Both Preact and Inferno are looking at supporting it but have been delaying it due to the amount of rewriting of the patch and render algos. Mithril does now currently support this. Personally I don’t think this is worth implementing in Hyperapp and Picodom since it would require quite a bit of extra code for a trivial feature that we can live without. My opinion. The React crowd got along fine without it for years. I understand the support for it in Babel and Buble is still kind of flaky.

Maybe after other micro-libraries have managed to implement support for it you might want to take a look at how they did it.