Per this example using current unstable picodom @2.0.0

https://jsfiddle.net/4eunk2um/

Click to remove elements from the list, and note how the removed element always ends up at the bottom of the range - because it doesn't get destroyed until 2 seconds later.

Keyed updates presumably exist, for one, so you can do this sort of thing?

About class components (https://github.com/jorgebucaran/superfine/issues/134), I was thinking, what if we could do something like this?

import { h, Super, patch } from "superfine"

class Hi extends Super {
  state = { say: "Hi" }

  render = () => (
    <h1>{this.say}</h1>
  )
}

patch(null, <Hi />, document.body)

Just throwing crazy ideas out there?

I noticed that onupdate doesn't fire during the first update, is this intentional?

I think, in most systems that offer both a create and update notification, the initial creation triggers both a create and an update notification, because there isn't typically much use for an update notification that doesn't fire the first time.

Typically the notifications you need are for creation, for destruction, or for all updates - rarely does anyone need a notification for "all updates except the first one".

Thoughts?

Having parent as first argument works very well when the all app is designed and wrote with picodom but not that much when used in a mixed libs app. (yes it happens in real world)

You cannot then just render / create a component to get its main node and then append it manually to a parent node of your choice at the time you choose.

To get around this you have to create a fake parent with document.createElement but that add a useless layer.

I'm also not a big fan of that kind of dependency injection and lake of separation which introduce a dependence between the child and its parent, I do prefer the other way, parent knowing its children, but I think this is just a matter of taste.

4b3593b23cc49e367aa8d019af84105e2bd81c6f dropped support for lifecycle events without much fanfare, what's the rationale and the recommendation for implementing features that would otherwise have been implemented with lifecycle events (e.g. hyperapp had a thorough discussion about a similar change).

I've added some sample TypeScript files to validate the typings in the repo.

• add JSDoc comments
• add lifecycle methods and key property

I've taken the feedback from @Swizz PR in hyperapp and incorporated it here. Let me know if I've missed anything.

I'll be adding comments to the PR about the reason for each change.

Resolves #34, #35

It appears the onremove event isn't triggered for children, when the parent is removed - I believe the following test demonstrates the problem:

https://github.com/mindplay-dk/picodom/commit/f108584890bdc936b44e8db5c071384bae3f3476

Looks like a bug? I'm unsure how to address it.

I don't want this merged — only for discussion. All of the unit tests are passing, however I'm sure this change has unintended consequences that are not covered by the tests.

Changes I'm proposing are to add a computed key based on the passed attributes — keys only as values are more likely to change between renders. If attributes are added/removed between renders then the element will be reinserted and can be solved by specifying a key manually, but I do believe that attributes are generally consistent between renders – only their values will differ.

Due to above change I've had to modify one of the tests where an attribute was removed (xlink:href). It was failing because an attribute was removed and so its key differed. Solutions to this are:

• Specify the key manually (chosen solution for the test);
• Select the use again (via querySelector) as it's a new element;
• Be explicit and add "xlink:href": null to the attribute list;

[email protected] is coming to you very soon. The signature of patch 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 patch, the first time you call it, and every other time.

SSR recycling is enabled by providing a recycleElement 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

Currently, the patch() function treats every JSX attribute simultaneously as a property and an attribute - it initializes both, which means you have no ability to update them individually.

Blindly treating every JSX attribute as both a property and an attribute means that most updates are unnecessarily being done twice - one of them generating either a meaningless property or a meaningless DOM attribute. The DOM accumulates a lot of garbage this way.

For example, <div innerHTML={content}> will inject literal HTML via the innerHTML property, but will also create a useless innerHTML attribute - or in some cases, such as <input value={value}>, will initialize the value twice, first using the value property, then again using setAttribute('value', ...).

I don't have a lot of references, but snabbdom for one separates properties from attributes - which seems sort of inevitable, at the VDOM level, if we want to solve this problem?

I really love new simplified patch usage and the simplified algorithm.

However, it seems we assume that the node.parentNode always exists in https://github.com/jorgebucaran/superfine/blob/master/src/index.js#L265

This works for the most part, but fails when the provided node is a DocumentFragment, since DocumentFragment won't have a parentNode.

The patch in this case errors out with:

To add more context, I have a web-components wrapper based on Superfine, which was invoking the patch in v6 as https://github.com/osdevisnot/supertag/blob/master/src/supertag.ts#L94

With V7, I believe the correct usage would simply be something like:

this[ROOT] = patch(this[ROOT], this.render());

But this fails with above error since this[ROOT] is a DocumentFragment created using

this[ROOT] = this.attachShadow({ mode: 'open' });

Any pointers on how we can use the V7 patch with DocumentFragments? Or am I missing something?

This addresses my issue #188.

This PR would allow you to write views that create shadow-roots. For example when using JSX:

function view () {
  return <div>
    <h1>Heading 1</h1>
    <div>The styles inside this shadow-root below are completely scoped to that node. This pairs great with importing CSS from JavaScript imports.</div>
    <div shadow-root='open'>
      <h1>
        <style>{'h1 { display: flex; padding: 12px; color: white; background: dodgerblue; } div { padding: 0 24px; }'}</style>
        <button onclick={increment}>Increment</button>
        <div>{state.count}</div>
        <button onclick={decrement}>Decrement</button>
      </h1>
    </div>
  </div>
}

Where the DOM output would look like: (The root h1 inside shadow-root is required to mount children into it and the parent div has to exist so we have a place to mount the shadow-root to.)

Here's a codepen of the PR in action. https://codepen.io/dustindowell/pen/rNYeLxg

If this is not something you're interested in it's no problem! I just think it's really cool to have encapsulation of styles and scripts without having to touch the custom elements api!

To briefly walk over the changes.

• I added a slot variable, because children will need to go into the shadow-root instead of the original node if the property shadow-root exists.
• Inside the new condition, these are the minimum steps needed to create a new shadow node. Shadow root elements can only be a few different tags. The list of valid root tags can be found here: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow. However the most common is obviously <div>. ~~I defaulted to div because I couldn't think of a good way to configure that. This is maybe something that could adjusted.~~ (see changes)
• Finally, changing the node.appendChild to slot.appendChild so the children nodes are appended to the correct parent node.

EDIT: ~~Perhaps a solution to configuring the node you attach inside the shadow-root would be to not allow "fragments" inside a node which has a shadow-root property. I'll think about this and make some changes.~~ (see changes)

EDIT 2: ~~I also didn't account for patching. 😅 So I do have some work to do still.~~ (patching works fine)

Wouldn't it be a nice and useful feature if superfine supported ref pseudo properties like React, Preact, Dyo, uhtml etc. do?

const elemRef = { current: null }
// [...]
const content = h('some-element', { ref: elemRef })

Here's a little demo (based on a R&D web-component toy library that uses a ref-supporting patched version of superfine internally): TypeScript version JavaScript version

FYI: Here's a naive quick'n'dirty implementation which obviously only provides part of the requested functionality: LINK

React has unmountComponentAtNode, preact has render(null, element), etc.

How would that work in Superfine?

patch(null, null, container) // ?

// or

unmount(container) //?

What is it expected from this operation?

@andrewiggins I figured I'd create a separate issue for this one, since your work is already enough to get projects up and going without it.

It would be great if we could also get some type-checking for elements and attributes - standard DOM as well as pico's oncreate etc., and possibly SVG elements. (does pico support SVG?)

I tried something like [elemName in keyof ElementTagNameMap]?: any; in the IntrinsicElements declaration - I think I've seen others doing something similar, but I couldn't make it work.

Snabbdom redeclares the whole kit'n'kaboodle, I guess maybe that's a necessary evil if we want type-checking for elements/attributes?

Either way, we can leave this for a future version, once the overall type-declarations are fully in place.