Container: children filtered with a selector

[tkrugg]

Sometimes not all the child nodes of a Container have the same importance. Some DOM is there just for decoration. It would have been if the API of Container.js could accept a property "childSelector" that would allow the user to designate the child elements which are to be considered children of the container. The current API doesn't offer much more the DOM API can.

A few use cases I have in mind:

<some-container-widget>
    <article>...</article>    
    <hr role=presentation>
    <article>... </article>
    <hr role=presentation>
    <article>... </article>
    <hr role=presentation>
...
</some-container-widget>
<!-- child Selector could be "article" -->

<ul is="some-container-widget">
    <li role=presentation> <a href="#">Link</a> </li>
    <li role=presentation> <a href="#">Link</a> </li>
    <li role=presentation> <a href="#">Link</a> </li>
...
</ul>
<!-- child selector could be "a" -->

[wkeese]

I don't get it. Why would the application add DOM that it wants to be ignored? That just bloats the download. For the first example, the application could write this, and it would display exactly the same:

<some-container-widget>
    <article>...</article>    
    <article>... </article>
    <article>... </article>
</some-container-widget>

[tkrugg]

no, I didn't mean the non important DOM would be ignored, the <hr>'s would still be there, filling their purpose (semantic and decorative), but :

• when calling .getChildren() if would return a list of articles and ignore the <hr>s

[<article>...</article>, <article>...</article>, <article>...</article>]

• when calling .getIndexOfChild(2) it would return the second <article> rather than the second node of the container (which in this case would be a useless <hr>).

[wkeese]

I see.

It seems like a scary API change, especially in your second example where getChildren() returns grandchildren rather than children. This might better be handled in the widget with (for example) this.containerNode.querySelectorAll("article")

Also,.getIndexOfChild(2) doesn't make sense; the API is actually .getIndexOfChild(node) and it returns 2.

[tkrugg]

getChildren() returns grandchildren rather than children

I agree. Plus I still don't see how addChild and removeChild would act regarding this. It doesn't make sense to define some selector, and then to be still able to add or remove any kind of node. The user is left with the array returned by .getChildren, which can be filtered with $.is().

That said, I still find this use case quite common for container, so maybe we can find a way to ease it?. Could we consider adding an optional parameter such as getChildren("article") and getIndexOfChild(2, "article")? Unless you think adding two other methods for this feature is safer, and maybe use Descendant rather than Child in the name to avoid the confusion.

[wkeese]

OK, well that would be pretty easy to implement, it's just that I haven't seen the need for this feature ever (despite the fact that you "find this use case quite common for container"). Would this feature help one of the deliteful widgets? If so, which one, and how?

[mythic2]

I cannot speak for tkrugg. My real case scenario, which might fit here, is: I am developing a wizard dialog with help of viewstack, some pages should be visible/hidden depending on selected options on previous pages. For me it is easier to define complete wizard as a single template, but then a more complex logic is needed for previous/next buttons as they have to figure out if there are some pages which should be skipped. A selector like page.d-shown would be helpful here.

[wkeese]

Closing this ticket just because so much time has passed and because we're unlikely to ever implement this enhancement.