omniscient on top of vtree + vdom

[Gozala]

I'd be like to get omniscient to a point where it can be used with vtree+ vdom instead of react for few reasons:

1. Pure functional philosophy seem to match better.
2. I'm interested in running some components in the web worker which is relatively easy with vtree + vdom
3. Unlike with react vtree can be used with any namespace and has no attribute blacklist, which enable me to use it with xul and not yet standard / not yet supported html attributes.

[Gozala]

I'd be willing to give it a shot, as it maybe enable me to omniscient for the a next project.

[Gozala]

I just need to know if project owners will be interested in taking patches to enable this.

[phated]

This seems like it should be an adapter that can be passed to withDefaults instead of completely changing the guts of this lib.

[Gozala]

@phated sure passing something to withDefaults seems like a good path to introduce alternative to react. That being said it's hard for me to speculate whether it will still require changes to guts of library, I suspect it will as there are no lifecycle methods in vtree, it's approach is define a function that returns a vtree and use whatever caching mechanism you want internally to return same tree if passed arguments are equivalent ones passed previously.

[mikaelbr]

As I mentioned on Gitter, as there are a few things that's "missing" from usage with virtual-dom and React, I don't think Omniscient is/should be quite capable to have this as a drop-in replacement, but I think a good approach would be to have a separate module patching the differences between React and virtual-dom, and this can be passed as an "modifier" in withDefaults.

This module would need something like: Mixin support, patching shouldComponentUpdate, methods for creating components (instead of React.createElement and React.createClass).

I think it makes sense having this outside core, to avoid many ifs, it nots and thens and all other switch cases. As maybe 95% of the cases with Omniscient would use React.

[torgeir]

I'd say have at it! I'm also for a something separate, but pluggable, and a couple of more hooks in omniscient in contrast to a complete rewrite. But I reckon some changes are needed. Why don't you have a go and see what path it takes

[dashed]

Someone had concerns on depending on a specific virtual dom library, and was able to create something that would compile to various targets:
https://github.com/gcanti/uvdom
https://gcanti.github.io/resources/uvdom/demo/views.html
https://gcanti.github.io/2014/10/29/understanding-react-and-reimplementing-it-from-scratch-part-1.html