How to render a section once for a nonempty list?

[jgonggrijp]

A regular section can render conditionally and will iterate over a list. Here lies a problem: what if you want to render the section exactly once if the list is nonempty, regardless of the length of the list? This would make it possible to render, for example, a <ol>...</ol> wrapper if a list is nonempty but not if the list is empty.

This question has come up many times. Some of the previous discussions include #14, #109, #147 and #152. #153 and #155 are relevant as possible solutions.

In #147 (comment), I made the following table of possible ways to address the use case. I suggest centralizing further discussion here and will keep the table updated.

Approach	Pros	Cons
1. Preprocess data to add a boolean ({{#listNonEmpty}}{{/listNonEmpty}})	Portable, no template language modifications required	Preprocessing not always possible for template author
2. Host language specific notation ({{#list.0}}{{/list.0}}, {{^list.isEmpty}}{{/list.isEmpty}}, ...)	No template language modification required	Implementation-specific, convenient subkey not always available
3. Special purpose sigil ({{?list}}{{/list}})	Shortest notation in this comparison	Sacrifices a special character for a very narrow use case
4. Power lambdas ({{#nonEmpty.list}}{{/nonEmpty.list}} or similar)	Powerful language feature that facilitates many use cases at once and does not introduce new special notation	Complicated to use for the lambda author, not widely implemented
5. Key modifier ({{#?list}}{{/?list}})	Short notation, does not sacrifice a sigil, no data preprocessing needed	Gliding scale: are we going to introduce key modifiers for every narrow use case? Also not widely implemented, and possibly conflicting with existing keys.
6. Filters ({{# list | nonEmpty }}{{/ list | nonEmpty }})	Single language feature with versatile applications, no new sigil	Does introduce new syntax, not widely implemented
7. Virtual keywords ({{#list}}{{#@first}}{{/@first}}{{/list}})	Familiar for Handlebars users	Special case in implementation, possible conflicts with existing keys
8. Doubly inverted sections ({{^^list}}{{/^list}})	Logically elegant	Potentially disruptive change for implementations that only serves this particular use case
9. Else clause inside inverted section ({{^list}}{{|}}here{{/list}})	General syntax that could also serve other purposes	New syntax, new sigil

Option 5 is what was proposed in #147. Option 9 was proposed in #171 (comment). At the time of writing, my personal ranking of preference would be 6>9>4>7>1>5>8>2>3.

[agentgt]

To continue discussion of originally #147

(...) what I think what @spullara is doing with the decorator at an abstract level is somewhat similar to adding virtual keys like Handlebars does of @index, @first and @last especially if this is happening automatically (which I was unclear on but I assume when Mustache.java sees a iterable it can auto wrap I think).

Thanks for clarifying!

I'm massively in favor of the virtual key approach:

• It seems simple to implement
• It seems simple to understand
• It has precedence with Handlebars

That last one is really important because when you see this question popup on stackoverflow tons of people will respond with confusion to use @index and @first etc because of Handlebars even though it is a mustache question. Or they respond with list.0 because of janl Mustache.

Sorry to disagree, but I think that filters are a much more elegant solution. They do not require special cases built into the engine and they do not introduce keywords that might conflict with pre-existing tag contents. Also, the filters themselves are generally really simple to implement. Filters can be further discussed in #153, if desired.

You don't have to apologize! I have wavered back and forth on not liking the virtual key approach for sometime from a purist and academic of which I am naturally and I do agree it is nasty and special case possibly on the verge of bloat.

However this is less about syntactically/semantically expressibility and more about "standard builtins".

If we don't provide a standard set of filters (or power lambdas) it is the exact same problem.

And I largely disagree on the collision problem because inner tag name content was largely never specified you very well could have tag names (key) of foo|first. Its actually even worse because they could have foo|first as a tag and if we provide some standard filters like first (which I will get to) then the collision is even greater.

Let us go back to the user who is not so comfortable writing lambdas or filters or is not even allowed to. Which filter do they use to mimic @first? For them it doesn't matter that they have to type {{blah | first}} vs {{@first}} one of which is a lot more complicated than the other.

So I'm in agreement with @spullara in that it would be nice to have an optional/recommended enhancement to the spec. Even just called best practice. Not a requirement but a recommendation of these keys could be special. If you are a new implementer consider not allowing them for general use. After all you are saying the same thing with | which will no longer be allowed to be used for a tag.

I'm not sensitive to the "somebody else already did it" argument. There are lots of ideas around that I believe are better not copied. We are not standardizing list.0, either. Users may be asking for @index etcetera, but I'm hopeful that they will accept an equally potent alternative.

Look I'm from Java camp. Java is late mover strategy to the max but at least Java has a ton of builtins (however it is massively still lacking the complaints are still high).

When I said handlebars has precedence I actually mean almost every templating language in the Java ecosystem has first/last/index:

For example:

• https://velocity.apache.org/engine/2.3/vtl-reference.html#foreach-loops-through-a-list-of-objects
• https://freemarker.apache.org/docs/ref_builtins_loop_var.html
• JSTL
• https://www.thymeleaf.org/doc/tutorials/3.1/usingthymeleaf.html#keeping-iteration-status

(I can keep adding to the list later if it helps as there are more than the above).
The ones that do not btw are appear to be the most "logical" where you are basically programming (rocker, JTE, old school JSP).

I just want to keep some perspective that Mustache is used by many people that are less technical and largely successful precisely because it does not have a lot of logic to teach. Also one of its greatest impacts of the logicless is that it is possible to make it much more secure in environment with non-platform developers. I'm not saying filters cannot be constrained but it will increase surface area.

A binding is a lot simpler than a filter and I think virtual keys largely can be done today for most implementations without changing the tokenizer. To @spullara point while it is special case it is less "logic" than bindings which is ultimately at the spirit of Mustache.

I'm very wary of things becoming like XSLT or Scheme. Pure but the damn batteries are missing.

[agentgt]

I dig orthogonality, perhaps because I'm more of a C++ guy.

It is funny you mention C++ because C23 (the C language specification) is adding things like bool to be more inline with C++. Kind of like how Mustache might want to had @first, @last, @index 😉 to be more similar to its superset: https://en.cppreference.com/w/c/language/bool_constant

That being said I understand where you are coming from (also the addition of the above was controversial).

To each his own, I guess. As I understand it, option 7 is your top preference. How would you rank the other options?

For the particular problem of 90% of list logic yes. I think Mustache OOB should be able to generate a comma delimited list without custom filters or lambdas.

That being said I think adding virtual keys might be mutually exclusive of adding power filters/lambdas. It is more let us make the exceptionally common should be easy path really easy and less error prone.

Lists especially since they can be inherently stateful (I'll avoid the academic part but order sort of requires state). You either transform the data to a new decorated list (which I hope would be the normal case for power filter) or you are doing disturbing state keeping with an accumulator of which many languages may not want to support.

However power filters still can fix the overall problem of passing things that cannot be passed to lambdas by current syntax such as list and bool (I believe that is what we are calling the "masking problem" right?).

[jgonggrijp]

You would only need regular filters for list iteration. The masking problem refers to having the same key on multiple levels of the context stack, where the highest occurrence makes the lower ones invisible (see #154). The masking problem is the only use case (that I know of) where filters would need to be supercharged.

I wouldn't say that Handlebars is a superset of Mustache in the way that C++ is a superset of C. I rather see it as a fork of Mustache that evolved in a different direction, with less emphasis on elegance and more emphasis on bells and whistles. Despite having way more bells and whistles (and being orders of magnitude larger than Wontache), Handlebars does not support every feature of the Mustache language.

You might be right that virtual keys and filters are mutually exclusive. I feel that embracing virtual keys instead of filters would kill the minimalist spirit of the language.

By the way, in your previous reply you mentioned shipping of filters with the implementation. That is a potential need I recognize, too. I briefly mentioned it in #156.

[agentgt]

I just realized I didn't answer your question about the other options rank!

I guess I just don't think knowing a whether a list is empty really that important as it doesn't fix the bigger problem of trying to do a CSV.

So its basically

7, 4, 6, 8.

The rest I don't see much value in as 7 is basically a superset of the other special sigil/symbol ones.

I am not really a fan of 8 yet that much as I have fears it will break lots of things where as the others are mostly additions.

7 and 6 are mostly you better not have a tag named this or have | in it where as 8 I'm not so sure.

(as for the C++ stuff that was mainly me coming up with some crappy rationalization 😄 ).

On a separate note I can't find a discussion of what I was calling the list/boolean problem of being able to pass an entire list or boolean that is top of stack. I assume power lambdas can fix that problem correct?

That is {{#list | filter}} (notice section), the filter would get the entire list as an argument and not one item at a time like {{#list.filter}} (for brevity just assume filter is hanging off of list or is ambient).

[jgonggrijp]

{{#list | filter}} would pass the entire list to the filter at once, as you wrote, but {{#list}}{{#. | filter}} will pass each element to the filter separately, one at a time. Depending on the need you can also use an interpolation tag on the inside, so {{#list}}{{. | filter}}. Or, if you want to only pass the first element through the filter: {{#list | first | filter}}.

I would expect {{#list.filter}} to pass the entire list to the filter (lambda) as well. The entire name (or pipeline) inside the tag is evaluated before the behavior of the tag kicks in.

Power lambdas could potentially fix any problem you want, if you make them powerful enough. With features 1-3 that I listed in #155, you could all the things I just demonstrated with filters, but at the cost of those lambdas being much more complicated than their equivalent filters would be.

[agentgt]

Whoops I made a typo when I said

I assume power lambdas can fix that problem correct?

I meant filter. I rather power lambda not be too powerful.

As for the ranking 4 and 6 are kind of swappable depending on what you need or want in the list and/or how they end up.

[spullara]

I'm still of the opinion that the best option is for people using mustache to default to putting the logic in the backing code and just get used to that or use a wrapper around lists. Barring that, there is at least one easy option that is missing:

{{^^list}} - {{^list}} already means "{{#list.isEmpty}}.." and if we generally think ^ means negation this could be a simple solution with unlikely overlap with current templates.

[jgonggrijp]

Thanks, I will add that to the table as option 8.

You prefer option 1. How would you rank the other options?

[spullara]

8 (^^), 3, 5, 2, other ones are too broad for this problem to motivate them.

[jgonggrijp]

Do you mean you prefer a solution that is as narrow to the problem as possible?

For me it is the opposite. I much rather have one solution for a million problems than ten solutions for ten problems.

[clach04]

@jgonggrijp Thanks for bringing this up, I was about to open a new discussion/ticket today on this topic!

My personal preference; 3, 8, 5.

I'm using an implementation that has 3 - https://github.com/clach04/stache#existence-check-exists (implementation from https://github.com/hyperturtle/Stache)

5 has the potential to cause problems for some existing templates (I do not use variable markers with a question mark prefix BUT it is possible, albeit maybe not plausible 😉).

Suggestions for updating the table for:

1 - A variant of this is described in https://stackoverflow.com/questions/11653764/mustache-how-to-detect-array-is-not-empty/70478815#70478815 - basically you have a single value hash/dictionary with a value of a list - which leads to nesting in the template (I've not tried this as I'm happy with 3 implementation I've been using the past few years).

2 - .length appears to be common in js implementations.

Related discussions; janl/mustache.js#683, robertknight/qt-mustache#22, #138, mustache/mustache#118

[jgonggrijp]

I'm using an implementation that has 3 - https://github.com/clach04/stache#existence-check-exists (implementation from https://github.com/hyperturtle/Stache)

Nice. Please feel welcome to give a general introduction to your implementation in Show and tell.

Suggestions for updating the table for:

1 - A variant of this is described in https://stackoverflow.com/questions/11653764/mustache-how-to-detect-array-is-not-empty/70478815#70478815 - basically you have a single value hash/dictionary with a value of a list - which leads to nesting in the template (I've not tried this as I'm happy with 3 implementation I've been using the past few years).

This is a variant of option 1 (preprocess the data).

2 - .length appears to be common in js implementations.

This is a variant of option 2.

Related discussions; janl/mustache.js#683, robertknight/qt-mustache#22, #138, mustache/mustache#118

Thanks for the useful references!

[jgonggrijp]

Please feel welcome to give a general introduction to your implementation in Show and tell.

Needless to say, this invitation extends to everyone who has written or maintained a Mustache implementation.

[clach04]

I'm using an implementation that has 3 - https://github.com/clach04/stache#existence-check-exists (implementation from https://github.com/hyperturtle/Stache)

Nice. Please feel welcome to give a general introduction to your implementation in Show and tell.

Posed to #171

Suggestions for updating the table for:
1 - A variant of this is described in https://stackoverflow.com/questions/11653764/mustache-how-to-detect-array-is-not-empty/70478815#70478815 - basically you have a single value hash/dictionary with a value of a list - which leads to nesting in the template (I've not tried this as I'm happy with 3 implementation I've been using the past few years).

This is a variant of option 1 (preprocess the data).

2 - .length appears to be common in js implementations.

This is a variant of option 2.

Those numbers were not coincidences 😉, I was suggesting updating the table with those additional notes at those table positions.

For example:

2. Host language specific notation ({{#list.0}}{{/list.0}}, {{^list.isEmpty}}{{/list.isEmpty}}, {{#list.length}}{{/list.length}}...)

[jgonggrijp]

Ah, right. I want to keep the table small, though. Do you think it makes a world of difference if I include your examples?

As for Show and tell, you showed feature 3. That is basically an idea for a feature, which had no dedicated discussion yet, so I moved it to the Ideas category.

I meant to invite you to show and tell about your fork of Stache. Not just the nonemptiness check feature, but all of its features, your rationale for making a hard fork, basically any story you might like to tell about it.

[clach04]

Ah, right. I want to keep the table small, though. Do you think it makes a world of difference if I include your examples?

Not life changing :-D

As for Show and tell, you showed feature 3. That is basically an idea for a feature, which had no dedicated discussion yet, so I moved it to the Ideas category.

I meant to invite you to show and tell about your fork of Stache. Not just the nonemptiness check feature, but all of its features, your rationale for making a hard fork, basically any story you might like to tell about it.

Will do.

[jgonggrijp]

I look forward to it.

One Discussions notice: unlike issue tickets, you can choose between directly replying to the top post or replying to an answer. Can you find the box that will let you reply to this message?

[clach04]

Thanks for the very gentle and friendly tip (I'm more familiar with issues), I think so 🤞. I posted #172 about my fork

[jgonggrijp]

You made it! 👍

[clach04]

I'd like to see 9 implemented, I like the idea and the syntax... but it's not a complete solution for me (more details). I can see myself using an if not, else which is similar in intent to the request in janl/mustache.js#683

I still need/want a if ;-)

Alternative idea which merges 3 and 9 into an if else:

{{?list}}
it is truthy
{{|}}
it is falsey
{{/list}}

No changes to existing implementations, so no surprises. You have to opt in to use the new syntax/feature.

[determin1st]

the syntax of | section is not disruptive, it was a proposed feature long time ago: https://writing.jan.io/mustache-2.0.html
there you may see that it goes first under Else name, which i initially accepted, but then mentally moved to the OR, because there are more to add to it and logic-less inclination should replace imperative expressions (common to if/else where you use AND/OR) with straight selections (common to flow control).

i see the further evolution of | as the SWITCH block, the block which may contain multiple OR sections, for example:

{{^number}}
  zero (primary section)
{{|}}
  non-zero
{{|123}}
  number that equals to 123
{{|1|2|3}}
  number that is 1 or 2 or 3
{{/}}

here, the case of {{|}} (lets say it is an unconditional OR which negates the primary section) and the primary section are special, they are applied before the SWITCH seek when the number is not a number, for example - it is an array (empty or non-empty), or, after the SWITCH seek, when the number is not found - selection of the default takes place. this block type arise only from # and ^ types and an advanced (conditional OR) {{|something}} section inside, otherwise implementation should throw an error while parsing the template. also, it is designated for numbers or strings - keys, other values are not recommended.

my preference rejects putting boolean values onto the stack {{#bool}}{{.}}{{/}} (except while iterating/traversing arrays), so

{{#list_is_not_empty}}
  is not empty
{{|}}
  is empty
{{/}}

{{^list_count}}
  is empty
{{|}}
  is not empty
{{/}}

encourage the use of helpers, doing pre-analysis of the data, which will reduce the logic in templates and make them more readable/understandable/friendly. i see no cases where pre-processing is not available, even in the playground, data may be automatically analyzed and a hashmap with name postifixes (like array-count and array-nonEmpty) added for each array encountered in the data.

[agentgt]

Yes that helps. The diagram confused me because it was unclear if the helpers were put on the context stack.

wrapper is the data, mustache doesnt differentiate data from wrapped data, the drawback is necessity to enter data or data.key everywhere instead of key.

And this helps me more understand more than the image. This is because others do this differently particularly for the case of iterating over a list.

As discussed in this thread #153 (reply in thread) and I will find a couple of others but many including Handlebars follow my number 4 (the keys do not exist at all on any data).

(it is spread around because I should have followed @jgonggrijp of making a top level of virtual keys which I will do later next week).

The virtual keys approach I and others took as while sort of legal and syntactically OK is as
@jgonggrijp noted "disingenuous to the user" (I will find comment later). I think @jgonggrijp is right and while I like virtual key and decorating I am now more convinced that the filters approach is more explicit. That is you are adding keys and data that is not theirs but with the filter approach the user is "opting" in.

The filters comments or on #153

[determin1st]

filters filter. pipes are from command line. lambda argument is the future of mustache.

[jgonggrijp]

@determin1st I now agree that your fallthrough syntax is not that disruptive. I removed that "con" from the table and replaced it with "new sigil"). The idea has also grown on me and is now my second preferred solution, after filters but before power lambdas. I started a new discussion about it in #178.

@agentgt I don't recall writing that virtual keys are disingenuous to the user. If I did, then I no longer agree with that statement. However, I do recall writing that the feature is somewhat magic-y/logic-y and implying that users have no choice in the matter. I still agree to those sentiments. Regardless, I'm happy to read that you now prefer filters over virtual keys!

[agentgt]

@jgonggrijp I was confused with a comment on how JStachio handles global or ambient like lambdas.

#135 (comment)

Also I can just say lambdaNotChildButSomeWhereUpTheStack is hanging off every node magically and therefore not in violation of spec (also if there was field with that name it would take precedence).

Better just be honest that your implementation is doing something nonstandard. 😉 Please don't take this as a value judgement, though. Portability between implementations is a feature, and this is why we standardize. However, deviating from the standard is still fine, as long as it is a deliberate choice and you're honest about it. If your users know it, they can decide for themselves which is more important to them: the portability (for this edge case), or the feature that you are giving them in return (I'm guessing that is performance and type safety).

The reason I like the spirit of that comment of "being honest" is that virtual keys are sort of dishonest at least in my implementation.

For example assume we have filters implemented:

And some filter with loose javascript like:

function todo(node) {
  return  '[ ]' + node['@index'] + 1 + '. ' + node;
}

{{#someList}}
{{@index}} {{! ok }}
{{ . | todo }} {{! will fail because @index is not a child }}
{{/someList}}

However if we do a enumerate filter we do not have that problem. We can pass the wrapped item.

{{#someList | enumerate }}
{{@index}} {{! ok }}
{{ . | todo }} {{! will not fail because @index on the wrapped nodes made by enumerate }}
{{/someList | enumerate }}

[jgonggrijp]

Very astute!