Ensure first patch handles server rendered keyed elements

[jridgewell]

No description provided.

[sparhami]

This used to work because entering a node created the keymap if there was none. A lot of changes a long the way haven't really been thought through enough that have introduced these sort of bugs. Even with this change there are still other issues around importing a server-rendered tree. For example, if an attribute disappears on the first render.

I'd like to take a step back and evaluate what is the best way to handle it rather than making these one-off changes.

[jridgewell]

This fixes a live bug with a current implementation:

var child = document.createElement('div');
child.setAttribute('key', 'key');
var container = document.createElement('div');
container.appendChild(child);

patch(container, () => {}); // => TypeError: Cannot convert undefined or null to object

---

As for ensuring we don't lose a keyed item, we could just test if keyMap exists here instead of lazy creating it.

[schmitch]

@sparhami is there any news here? I'm still looking into a way how to have a server-side rendered tree and then incrementally update it.

Actually I'm on the scala-js camp and we are trying to create our own library on top of incremental-js so I'm still figuring out on how to apply the incremental-dom, tree to our template library in a "performant" fashion.
But at the moment we actually render all our templates on the server, but we could probably create the same template engine on the client and parsing the template to a inc-dom tree.

What my current approach about server-side rendering is, would be a initialization method that will actually provide all the keys on the node and will block any update until this happens.
Would that be a good way to do it, instead of handling the first patch as "special"?