render() signature (again)

It took me a while to understand this issue.

I haven’t been keeping up with the latest updates - I see we’ve returned to the render(lastNode: VNode, nextNode: VNode, container: Node): Node signature.

@jorgebucaran what made you give up on the idea of just storing lastNode internally? why do we have to do this housekeeping ourselves?

As far as I can figure, this only invites bugs - there’s only one correct lastNode you could possibly pass in for any given call, right?

This isn’t a feature that enables you to do something clever by passing in something other than the actual lastNode state as returned by a previous call to render, is there?

Unless there is, this seems like unnecessary complexity.

If we’re trying to go more low-level, I’d prefer we went closer to the metal - closer to the internal patchElement, which probably has the real utility you’d be looking for if you were trying to implement a framework with some kind of stateful component concept.

My all-time favorite render signature thus far is:

render(target: Node | null, state: VNode): Node

And have it do the previous state housekeeping internally, like we had previously.

This will let you create new Node instances from a VNode instance, and then use appendChild or insertBefore etc. to achieve precise control of where the nodes get located - what we have now seems to favor easy over simple, and gets in the way when you need more control.

This being a library and not a framework, as I’ve argued many times, I still feel it’s problematic that we hide the real flexibility and power of the internal patchElement function behind a render function less functionality. As discussed many times, the forced 1:1 parent/child-relationship is an unnecessary over-simplification of patchElement, which can internally patch nodes directly - exposing this capability is going to be really important if we’re going to experiment with component models and so forth.

Hiding this essential functionality still doesn’t make sense to me.

Thoughts?

[mindplay-dk]

But hey, guess what?

const render = (node, container) => (
  container.$$vnode = patch(container.$$vnode, node, container)
)

render(<App />, document.getElementById("app"))

With that one-liner, I have exactly what I wanted - works like a charm, so I guess maybe we’re fine without having this feature in the library itself after all 😃

You might consider putting this in the README though, as an example of how to maintain state.

Along with the mount example maybe:

const mount = (view, container) => {
  let lastNode

  const update = () => (
    lastNode = patch(lastNode, view(), container)
  )

  update() // initial render

  return update
}

const App = () => <h1>Hello World</h1>

const update = mount(
  () => <App />,
  document.getElementById("app")
)

update() // re-render

I think, with these two minimal examples in the README, we’ve covered all our bases, and clearly demonstrated how to either maintain state in a closure, or inject state into elements - should be enough to get anyone started no matter their preferred approach? 😃

[jorgebucaran]

de5ec32a031510816d3c6380b9f6d4f1778d280b 🎉