Can BindingFunc be refactored to return ValidChildDomValue[] in addition to ValidChildDomValue?

[metaleap]

I have a funky case of a table with a mix of static and "dynamic" trs. _{(Form fields really, each row a label and input. So "dynamic" meaning custom user-defined "content fields" seamlessly merged in to domain objects are what I want here.)}

I right now have a type Field = { id: string, title: string } (to simplify) and so my bare-bones "forms component" has both a fields: Field[] (static fields) and dynFields: van.State<Field[]> init property.

When the latter has a state-change I don't want to re-render the former. That's why they're separated out explicitly.

Here's how I do things now, note the unwanted span I must currently do:

    const trs: ChildDom[] = _.fields.map(fieldTr) // fieldTr not included here, does tags.tr(tags.td(...), tags.td(...))
    if (_.dynFields)
        trs.push(() => tags.span(..._.dynFields.val.map(fieldTr))) // dont want to have to do the span here!!
    const table = tags.table({}, ...trs)

Whether I use span or div or data or whatever, it renders faulty (and strictly speaking, HTML-wise it is faulty — trs go right under table).

This function which must satisfy the BindingFunc however is not valid when returning an outright ChildDom[].

(I mean worst-case I could ditch the tables and render boxes / grid for this scenario, but they really have some perks in their built-in layouting esp. when considering potential nesting scenarios.)

[metaleap]

Well I already switched from the table/tr/td design to divs and it's fine. There might be other cases for the BindingFunc idea I asked about, but right now I'm not suffering any — so feel free to close thread at your discretion =)

[Tao-VanJS]

Hi @metaleap,

Thanks for reaching out!

I think for your case, <tbody> can be a good container elements for a group of multiple <tr> elements. Note that it's allowed to have multiple <tbody> elements within a <table> element, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tbody#usage_notes.