Closest ancestor as target element.

[RoelandSalij]

Hi,
For a pet project of mine I wanted to add classes to specific listitems in a listview.
So I added the option to look for the closest ancestor related to current element in the dom tree.
This enables you to set classes per item in a listview.
I'm curious what you think about the feature.

[sergiuszwoznicki]

Hi,

Technically, it looks ok. My doubt is about functional aspect. The primary aim of the widget is to manipulate css classes per global selectors by custom logic. Your case is different: your logic is implemented elsewhere (in your test project it's in the two additional containers per Chart Data list view item with conditional visibility: $currentObject/Series = N) and the only reason of using our widget is to set css class for LI ancestor (which is impossible by normal css selectors and requires JavaScript). It looks there are better widgets for this aim, e.g. Attribute Helper: https://appstore.home.mendix.com/link/app/111554/).

So my impression is that I'd rather leave the widget as it is and use another solution for your need. How do you think?

[RoelandSalij]

Thanks for your answer. And I do understand you do not want to add too much options/ configuration complexity.

I did look into attribute helper widget but it looks like this one explicitly disallows modifying the class attribute. So I'm not sure how I should utilize this widget to make my use case possible.

From that perspective the CSS Class Switcher comes closer to what I wanted to achieve: Switching CSS classes (for a specific element which is located by traversing to the root.).
It's not a problem for me to create a separate widget for my use case, but I'm torn a bit between doing that and keeping the number of widgets, in the App Store, that almost do the same but not exactly, limited. Otherwise, people will get lost in a wood of finding possible widgets to solve their use case.

My original use case is having the possibility to add classes in order to facilitate animation.
I achieve that by making the widget conditionally visible which triggers the widget and results in the animation classes added on user interaction.

But for that use case it would also make sense to not use a nanoflow and possibly pass in the context object, so that would justify a different widget.

[sergiuszwoznicki]

Thanks 😊

I completely agree with you about the issue of wood full of similar widgets.

As for the attr helper one, I’ve seen the limitation (no class/style attrib), but have you tried using it with a dedicated custom attribute like “data-listview-item-type”? You could then handle it in your CSS with by attribute selector [], e.g.:

li[data-listview-item-type=warning]{...}
li[data-listview-item-type=primary]{...}

And right, our widget has no entity context (doesn't need it in the original design); and using a nanoflow for each row just to return a static string seems wrong, at least from performance point of view.