Views that render a sub-view

[ludlovian]

New to domvm, moving from Mithril, so apologies if I have misunderstood

If I have a view that only renders another view, then I get an error of cannot set _node of undefined at

domvm/src/view/hydrate.js

Line 57 in 39113cd

vnode.el._node = vnode;

The problem goes away if, for example, View A renders View B inside a <div> or other DOM element, but it seems it doesn't like a view that only renders another view.

I have a small flems,io example which shows this in action

I can rewrite the existing components/views so that they wrap the sub-views, or become template producing functions, but wondered if this is an intentional restriction?

Oh, and thanks for what already looks like a great library.

[leeoniya]

hi @ludlovian ,

New to domvm, moving from Mithril

i was a Mithril user back when it had the concept of Controller (from MVC). that abstraction made no sense to me so i wrote domvm as a mix of the parts i liked in mithril and domchanger [1]. it has since evolved further from there.

If I have a view that only renders another view, then I get an error of cannot set _node of undefined

yes, views must currently return a single dom vnode.

I can rewrite the existing components/views so that they wrap the sub-views, or become template producing functions

yep, that's the way to do it.

but wondered if this is an intentional restriction?

it's not intentional, per se, but is a limitation/result of domvm's 1:1 vdom:dom architecture. it's also the reason Views cannot currently return null or fragments/arrays.

FWIW, i've not personally found the lack of direct view composition (views immediately wrapping views) particularly limiting, given that template composition can replace it for the vast majority of cases. fragments-from-views are in the same boat - nice-to-haves but not dealbreakers.

it's not impossible to add support for these features to the core but would require a non-trivial amount of internal modifications and considerations that i'm not entirely convinced are worthwhile. some of this is discussed in #195.

Oh, and thanks for what already looks like a great library.

thanks for trying it out!

[1] https://github.com/creationix/domchanger

[ludlovian]

Thanks for the swift response.

I think I can do what I want easily with template producing functions, given that element vnodes can contain private data and implement hooks on insert/remove - which is very often the only reason for me to use views/components.

[jlgrall]

yes, views must currently return a single dom vnode.

The only limitation I met was that sometimes I needed to insert a div because I could not directly return an array of elements. It messed my CSS, but it wasn't difficult to fix. It can also be annoying when you want to append different elements as direct children of the mount point: you need to make and mount as many Views.

[leeoniya]

it basically comes down to choosing between either redrawing the parent or having a wrapping div. in most cases i choose redrawing the parent/ancestor because i prefer a shallow/clean dom and the perf has never been an issue for me since i keep my dom limit at ~3k nodes and the median case is ~1.5k. even redrawing all 3k nodes is a < 2ms overhead affair on desktop and maybe ~5ms on mobile.

the most common case people have for wanting fragments is when you cannot insert a wrapper: flexbox nesting, dt+dd pairs [1] or a single item being represented by several adjacent trs in a table. in these cases you gotta either redraw the whole table or have another helper that tracks the indices of needed sets of trs and redraws/patches those as needed.

most of these are easily avoided or worked around. in 99% of cases, a parent redraw is the best solution.

@jlgrall

It can also be annoying when you want to append different elements as direct children of the mount point: you need to make and mount as many Views.

that shouldn't be necessary. have you tried vm.mount(placeholder, true); [2]. (it's in the docs, too).

[1] https://www.w3schools.com/tags/tag_dd.asp
[2] https://jsfiddle.net/q8vwpcax/1/

[leeoniya]

ping @jlgrall

[jlgrall]

that shouldn't be necessary. have you tried vm.mount(placeholder, true);

Thank, but that was not an option. I couldn't replace the mount point element, I could only modify it, because it was referenced in another script.

[leeoniya]

it doesnt get replaced, it actually gets absorbed and mutated. it will only get replaced if the tags don't match. check the demo more closely :)

[jlgrall]

The doc says it replaces the placeholder, I didn't try it :)

[leeoniya]

i guess it should say "absorbs or replaces" or 'hydrates" or ???

[jlgrall]

It would probably be more simple if mounting didn't append by default, and you would need to pass true as the second argument to append: vm.mount(target, append?). It would be more intuitive too.

Edit: in linux, when you mount a filesystem, it "replaces" the target's content.

[leeoniya]

i think both are equally simple.

if you come from linux, then your default for mount is certainly more intuitive. on the whole i'm weakly against changing it because it's a major BC without that strong a case. either way, it'll have to be a ride-along on some future v4 train.

at present, i just want to clarify the docs.

[cornelius-dol]

Agree with @leeoniya. Not worth breaking for and neither seems any more intuitive to me. Personally, I think the "true" behavior (updating the node?) is the better default, since it results in exactly the node specified, but again, not worth a BC; I do seem to recall being surprised by this early on.

[leeoniya]

the only thing that's not that great is that the placeholder can be <div id="foo" class="bar" data-cow="abc"> while the view root can be el("#baz.moo", {bat: "man"}). it's rather awkward, IMO, that the placeholder will get mangled and mutated during assimilation. i mean, it makes sense but could be surprising that the original id and class will be blown away, data-cow will remain and bat="man" added. what if there were styles for .bar {} or #foo?

I do seem to recall being surprised by this early on.

i probably will change it in a future major ver, but given that there are no near-term plans for a v4, it could be good while. unfortunately(?), domvm's API has been largely de-warted over its major versions, so justifying a v4 is tough, and this change alone certainly ain't gonna cut it.

[jlgrall]

Sorry, I didn't explain it, but it was just a thought on my part, I didn't expect you to change the API. I just think that sometimes it is good to see different or contradictory solutions. But yeah that would be a terrible breaking change.

it's rather awkward, IMO, that the placeholder will get mangled and mutated during assimilation.

On the contrary: domvm doesn't interfere with attrs that are not specified in the template, which I think is great because we can either keep or change the id, the class or any other attribute at our discretion. The designer can set the id he wants and domvm will keep it. Or if we wants to completely take control, we can replace the target.