Node recycling loops infinitely when encountering multiple component modules

[claytondol]

When creating multiple instances of the same component using domvm.defineView, if another element is removed from the structure before the components it causes domvm to enter an infinite loop while emitting the following message:

ALREADY_HYDRATED: A child view failed to mount because it was already hydrated. Make sure not to invoke vm.redraw() or vm.update() on unmounted views.

Fiddle showing issue (clicking the button will freeze your browser): https://jsfiddle.net/ohxtyuav/4/

• Moving vw(Dynamic) to be after the static components works as expected.
• Moving it to just before the final static component works as expected.
• Moving it to before the second static component doesn't completely seize up, but produces confusing effects; the second static component disappears alongside the dynamic one, and domvm thinks it's a foreign element: FOREIGN_ELEMENT: domvm stumbled upon an element in its DOM that it didn't create, which may be problematic. You can inject external elements into the vtree using domvm.injectElement.
• Leaving it where it is (before all three static elements) causes the infinite loop described above.

[leeoniya]

thanks for the report / repro. i'll try to take a look at this soon.

i have to admit, though, that i don't actively maintain this lib anymore. if the bug is sufficiently tricky to fix, it will probably stay that way unless someone submits a PR to fix it.

while domvm has some unique features, i would enthusiastically recommend that people use https://github.com/localvoid/ivi when starting new projects if they're exploring UI libs outside the big three/four. i plan on using ivi for all new projects myself. it has many API similarities to domvm (stateful component closure where only render() is re-executed, manual redraw facilities via invalidate(c), etc). it also has many advantages, such as much better performance, smaller size, returning fragments from roots, rendering portals, TypeScript support, etc. i collaborated with the author on the recently-released v3:

krausest/js-framework-benchmark#1234
localvoid/ivi#54

cc @lawrence-dol ^^

[l-cornelius-dol]

@leeoniya : That's good to know. We've invested a lot into code using VDOM so I'd like to take over this project. Is there an appropriate process to transfer the repo? What if other users come here, how would they find my fork from among the 27 other forks and know that it's being maintained?

[l-cornelius-dol]

Alternately, can I have your permission to just take the IIFE into a private repo in our company?

[leeoniya]

there's probably no need for a fork, i think you already have commit permissions here and i'd be happy to give you more if needed, e.g. to merge/approve PRs, tag releases, and publish npm packages.

i'm not dead just yet :), and would be happy to be a resource for any questions/guidance.

Alternately, can I have your permission to just take the IIFE into a private repo in our company?

this project is MIT licensed, so you can do that (and more) without my explicit permission. though this is in no way an "alternative" to an OSS maintainership commitment; they're completely different things. if you actually plan to maintain it and answer people's questions, fix bugs, and publish releases (i dont think domvm needs new features, except maybe fragments support, but that's hard) then that's great, otherwise i should probably put up a notice in the README about maintenance/archive status.

We've invested a lot into code using VDOM

nevertheless, i encourage you to play around with ivi; it's a fantastically engineered and externally-simple vdom framework with many of the same choices i designed into domvm but without any of domvm's papercuts. i did not like ivi's API before v3, so still prefered the ergonomics of domvm, but now i have no reservations.

[l-cornelius-dol]

@leeoniya : As an exercise in understanding the problem I wrote a green-field vDOM engine, which after a lot of work has successfully progressed into a full replacement for the parts of DOMVM that we use (view generation, rendering, components, and hooks). I was able to design a clean API, with complete consistency (the direct benefit of the combined experience with Mithril and DOMVM), with trivial porting from DOMVM, though not a drop-in replacement.

I will say this, it has given me deep admiration and appreciation of what DOMVM does, and how well it does it. It took a lot of effort to first match, then beat DOMVM's performance, match its memory footprint, and still beat the code footprint.

Thank you ever so much for your hard work with DOMVM -- it truly transformed my experience of front-end development. Mithril made FE dev good; DOMVM made it great.

PS: I did look over IVI, but it (a) breaks my no-tooling rule, (b) far more importantly, it follows the path of React et al with magical state and complex redraws, which is a deal-breaker for us, and (c) is relatively huge by the time you use any meaningful portion of it.