Should RevealWidget be extended to relieve ListWidget of simple comparisons?

#1

Fact1) Sometimes there’s an option to use either a ListWidget or a RevealWidget because there is a conditional testing depending on a state.

Fact2) The ListWidget is often used for conditional tests, such as to see if the current tiddler has a certain tag in which case it should also show a certain template.

…but I often wonder if the ListWidget, in all its glory, isn’t “too heavyweight” for such simple matters as a simple comparison?

So, might it be beneficial to extend the RevealWidget to allow for more complex comparisons, to avoid the ListWidget? I.e rather than the RevealWidget just looking at a state tiddler it could really evaluate a filter (…which is then compared using the match, “gt”, etc…)?

Of less importance, but still, it is conceptually weird to use a listing tool when the outcome is a obviously a single value (or no value). One such case is when you want a “headline” over some list, but you only want the headline if there is a list. I have previously proposed some feature in the ListWidget for this but the recommended way to solve it is to use two listwidgets; the first containing the “headline” and using the same filter as the second one but whith a +[first[]] operator thrown in. Clever… but definitely quirky.

So, would it make sense to extend the RevealWidget with a filter attribute? Or would that make it as heavyweight as the ListWidget so it kills the idea?

Or is this all just a non-issue?

Proposing category for "TW development"
#2

By the way, if the RevealWidget had a filter, then it could have a “binary” type comparison i.e “if the filter gives any output then…”

<$reveal type="binary" filter='...'>

#3

The list widget has 340 sloc (source line of code)
The reveal widget has 260 sloc.

As you can see at the numbers of sloc, there isn’t too much difference. So if you add code to the reveal-widget, there wouldn’t be any difference at all.

BUT a new eg: show-widget which has a “filter” parameter would probably have significantly less code. …

1 Like
#4

The reveal widget is “old” … They “type” and “match” parameters are only needed, because the filters we had at our proposal could not do “gt, lt, eq” and so on.

I think a new widget would only need a filter parameter and a very simple rule. … If the filter creates any output other than an empty string, the content of the widget will be shown.

I think that would be enough.

#5

Sounds excellent. And deprecate Reveal, right?

#6

Mat I do believe what you raise is importiant but another approach may be another widget. A light version of the list widget designed to accept filters and provide the alternate templates and not alter the current tiddler. The conditions that were unique to the reveal widget now have matching filter operators. We can even use the qualify macro in filters now.

Perhaps still with an emptyMessage or else but permitting it to be coded inline and given a template.

However i am now thinking perhaps a general solution for show hide or true false or if else because they can all provide the same outcome and meet your requirement while helping in other cases.

Actualy perhaps it could also include a case statement wherevthe nul case is the empty Message.

I will get back to you.

#7

It’s important to remember that although they overlap, there are distinct purposes for the reveal widget and the list widget:

  • The reveal widget generates a DOM node to wrap its content and thus can be used to drive animations
  • Because it generates a DOM node, the reveal widget can’t be used for things like selectively hiding an <li> because it would insert a <span> between the <ol> and the <li>
  • The list widget does not generate DOM nodes and so one cannot animate things hiding or showing
  • Because it doesn’t generate a DOM node, the list widget can be used for things like selectively hiding an <li>

Thoughts:

  • A replacement for the reveal widget that is based on filters would make a lot of sense, or to add the functionality to the existing widget as @twMat suggests
  • The name list is clearly not suitable for all of the use cases that it is now used for
  • I don’t think there would be much to be gained in a “light” version of the list widget from a performance perspective
  • As a general rule, if we want to make things easier to type then we should invent parse rules, rather than complexify existing widgets
1 Like
#8

I did some testing not long ago where I replaced the $list widget in some very complex widget trees with a minimal $if widget that used a filter. I was unable to find any quantifiable gains in performance, neither render/refresh speed nor memory consumption.

#9

I don’t know if this is unsanctioned (mis-)use of the RevealWidget, but I’ve been successfully using something like

<$reveal type="nomatch" text="" default={{{ [filter expression] }}}>
  Text to show if filter returns anything.
</$reveal>

With other types and texts this can be more complex, and it allows for arbitrarily complex filter expressions. Since it uses a filtered transclusion it cannot return lists and such, but those would be hard to match against text anyway.
Like Jeremy wrote, this only works if I can deal with the extra element that $reveal generates, but e.g. to show/hide a list item based on the filter, I could just add tag="li" to the RevealWidget, couldn’t I?
However, now reading about the similar SLoC between $list and $reveal and the quickness of $list (thanks @saqimtiaz and @pmario), I wonder if I shouldn’t just use $list, even though the semantics would dictate $reveal in many situations, even though I’m a pedant concerning semantics.
Have a healthy day
Yaisog

PS: Using tag="li" may not really work as intended, as the <li> is not removed from the DOM when the filter doesn’t match, but only left empty. That’s probably what @jeremyruston meant. So you’d need extra CSS like

li:empty {
  display: none;
}

to hide it. And that’s sort of hack-y.

2 Likes
#10

@saqimtiaz published a method to produce lists recently.

#11

That’s probably not going to happen, without breaking backwards compatibility :slight_smile:

#12

OK, maybe deprecate is the wrong term. What would you call how we treat the VarsWidget now that we have the superior LetWidget?

#13

Yep, the idea of using a “list” widget to accomplish a simple filter-conditional reveal is one of the counter-intuitive things that make TW somewhat intimidating for novice folks. It’s hardly a deal-breaker for choir-members like myself, but I’d be much happier if I could recognize instantly the difference between a true list and a “hide this next part unless…” maneuver.

#14

Could the RevealWidget maybe extended to have a filter attribute that “supersedes” the state attributes and could be nothing more than an alias for default={{{ }}}? Also, allowing e.g. tag="" to suppress the creation of a DOM node would give us all we need without implementing a completely new widget, while maintaining backwards compatibility.
Have a nice day
Yaisog