fixes#248
As snabbdom-jsx and snabbdom-jsx-babel hadn't had an update in 7 to 8 month and expecially the former has several bugs I would not advertise to use them.
Snabbdom-pragma works more reliable and thanks to a few PRs by me it works just as good with svg as it does with html
Cyclow is a new reactive frontend framework for JavaScript I've created. It uses Snabbdom. Please, consider add it to "Structuring applications" section. Thank you.
* Performance improvements for attribute patching:
- Avoid call to split and use a object lookup instead
- Simplify the code for `svg` name spaced attributes
* Fix typo and added missing property
* Fixing previous attribute ns assignment
* Refactor NS
* Add fast path for non namespaced elements
* Adding tests
This commit addresses issue #167. Previously, in snabbdom v0.5.0,
patch(element, vnode) would always create a new element for the root.
This resulted in problems with custom elements (web components), and was
fixed in commit c091c59c59.
However, that commit resulted in bug #167. This meant that snabbdom
would have bugs with server-side rendering, where the root element would
be non-empty (it has many children, rendered on the server-side as
HTML), and the client-side rendering should reuse those existing
children (or clear all the children and recreate them again in patch()).
This commit introduces the function toVNode(elm) that deep-converts an
element (and its tree) to a VNode (and its tree), that is separately
imported and used before calling patch(). toVNode(elm) will look at the
element's attributes and gather those as data for the vnode.
Overall, this commit is important for fixing #167 and enabling
client/server-side rendering in an efficient manner
(destruction/recreation client-side is probably too expensive).
This commit makes the patching algorithm ignore `null` and `undefined`
children. This means that, whenever children are iterated, the algorithm
must check for possible `null` and `undefined` values.
In order for other TypeScript code to consume snabbdom's TypeScript
correctly, we must "export" the modules/module interface just like
we export other types.