Nunjucks: "if" should consider an empty array to be false

[boutell]

nunjucks currently considers an empty array to be true. It is common practice in jinja and its other derivatives to test for an empty array by just writing {% if arrayname %}.

From the jinja documentation:

The if statement in Jinja is comparable with the if statements of Python. In the simplest form you can use it to test if a variable is defined, not empty or not false:

{% if users %}
<ul>
{% for user in users %}
    <li>{{ user.username|e }}</li>
{% endfor %}
</ul>
{% endif %}

[mbylstra]

Yes, this one had me scratching my head. What is the workaround?
_update_: this worked for me {% if users|length %}

[devoidfury]

In my opinion, this falls into one of the side-effects of Javascript vs Python.

In python:

not not []
=> False

And Javascript:

!![]
=> True

So I think {% if arr.length %} is more Javascript-y, and the current logic is valid. Just my opinion.

[boutell]

Sure, but nunjucks is not javascript. It's a template language which should do what feels most natural to frontend developers writing templates. Within the bounds of what can be delivered with reasonable performance at least.

[mattbasta]

No it's not JavaScript, but the only interface to Nunjucks (presently) is
JavaScript. It doesn't make sense for the host language to behave one way
and the templating language to behave in another way. The only benefit here
is to Python developers, but that audience is fairly small compared to JS
developers using Nunjucks.

Note that it's inconsistencies like this that make people rage at languages
like PHP+Smarty, where subtle and confusing one-off rules throw you for a
loop.

Also note that the performance cost of this is non-trivial because the test
needs to be performed on every comparison, since there's no way to know
what variables contain arrays at compile time.
On May 29, 2014 9:04 AM, "Tom Boutell" [email protected] wrote:

Sure, but nunjucks is not javascript. It's a template language which
should do what feels most natural to frontend developers writing templates.
Within the bounds of what can be delivered with reasonable performance at
least.

—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/nunjucks/issues/79#issuecomment-44549162.

[boutell]

You're right, the templating language should behave like the host language!
let's all use EJS (:

On Thu, May 29, 2014 at 12:14 PM, Matt Basta [email protected]
wrote:

No it's not JavaScript, but the only interface to Nunjucks (presently) is
JavaScript. It doesn't make sense for the host language to behave one way
and the templating language to behave in another way. The only benefit
here
is to Python developers, but that audience is fairly small compared to JS
developers using Nunjucks.

Note that it's inconsistencies like this that make people rage at
languages
like PHP+Smarty, where subtle and confusing one-off rules throw you for a
loop.

Also note that the performance cost of this is non-trivial because the
test
needs to be performed on every comparison, since there's no way to know
what variables contain arrays at compile time.
On May 29, 2014 9:04 AM, "Tom Boutell" [email protected] wrote:

Sure, but nunjucks is not javascript. It's a template language which
should do what feels most natural to frontend developers writing
templates.
Within the bounds of what can be delivered with reasonable performance
at
least.

—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/nunjucks/issues/79#issuecomment-44549162.

—
Reply to this email directly or view it on GitHub
https://github.com/mozilla/nunjucks/issues/79#issuecomment-44550342.

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | [phone] | punkave.com

[jlongster]

This is a good case to talk about, and there are places we make it easier for template devs (null/undefined are coerced to empty strings, etc). Those are very small things though, and I think we should minimize where we change semantics. As a JavaScript developer, I would be very surprised if an empty array did evaluate to false, so I have to side with others here that I don't think we should change it. Right now we can defer to JavaScript for most of the semantics for conditionals, and other edge cases in the language, and I think that's a good thing, because language specifications are hard and I don't want to have to specify a lot of edge cases in the docs.

Thanks for bringing this up though!