jgonggrijp
commented
1 year ago I personally wouldn't like to complicate the internal structure of tags in order to elide linebreaks. In my opinion, part of the charm of Mustache is its syntactic simplicity as compared to other languages such as Handlebars and Jinja. I think I could live with a dedicated linebreak- or whitespace-eating tag like {{~}}, though. That would also be relatively simple to implement; it would just be a tag that is always "standalone" (even if there is other content on the same line) and that does not render any output.
However, I can think of a few more alternative options.
1. Since you mention that partials would help, except that you don't want to create additional files for them, I suspect that you might like inline subtemplates (#63). I would personally prefer inline templates over a dedicated tag just to eat whitespace, since the former is a much more powerful feature.
2. Since you don't want any linebreaks, you could just render the template with linebreaks and then remove them afterwards in one sweep with the host programming language. Admittedly, this would amount to working around a shortcoming in the templating language, but it is a more economical option than you might think. In most programming languages, removing linebreaks from a string can be done in a single line of code. If you wrap that line of code in a function that also renders the template, you have a reusable oneliner that you can call everywhere you need linebreak-free output instead of the line that does rendering only. The total amount of code might be less than when you have to append tildes to every tag after which a linebreak should be elided. This approach, where Mustache does what it is good at while the host programming language takes care of the rest, is also commonly found when massaging the input data into a shape that works well for Mustache templates. While this might not the best option overall, I feel it is better than having linebreak elision syntax inside tags.
3. You can hide linebreaks inside any tag, not just comments. All specs allow arbitrary whitespace between the sigil and the contents of the tag, as well as between the contents and the closing delimiter:
{{#
content
}}In a way, you could argue that this is linebreak elision syntax already. Taking this to the extreme, you could put every tag on a separate line, without introducing any whitespace in the final output and whitout needing any additional tags. Below is how I might approach your example template:
{{#isFormParam
}}{{^isBinary
}}[FromForm{{^isModel
}} (Name = "{{baseName
}}"){{/isModel
}}]{{/isBinary
}}{{#required
}}[Required()]{{/required
}}{{#pattern
}}[RegularExpression("{{{.
}}}")]{{/pattern
}}{{#minLength
}}{{#maxLength
}}[StringLength({{maxLength
}}, MinimumLength={{minLength
}})]{{/maxLength
}}{{/minLength
}}{{#minLength
}}{{^maxLength
}} [MinLength({{minLength
}})]{{/maxLength
}}{{/minLength
}}{{^minLength
}}{{#maxLength
}} [MaxLength({{.
}})]{{/maxLength
}}{{/minLength
}}{{#minimum
}}{{#maximum
}}[Range({{minimum
}}, {{maximum
}})]{{/maximum
}}{{/minimum
}}{{&dataType
}} {{paramName
}}{{/isFormParam}}This is, admittedly, not as pretty as a template in which every tag starts and ends on the same line, nor is it pleasant to have a "frown" at the start of every line. However, I would argue that having dashes or tildes inside tag delimiters sprinkled across the template is not very pretty or legible, either.
dragorosson
Suppose I have this template that must render without newlines:
I could make this "more" readable by introducing comments across newlines:
I could use partials, but then each one has to go into its own file, which to me is too granular and hurts readability.
Reading through the spec, I don't see anything about trimming whitespace/newlines.
~to remove whitespace on that side of the statement, like{{blah~}}.-, like{{ blah -}}or{% if blah -%}.If there were such a feature, this template could be much more readable (untested):
Maybe a simpler alternative would be to have a separate
{{~}}statement that eats whitespace around/after it.