Comparison filters (@eq, @ne, etc.) should accept undefined as a key.

[smfoote]

If I have a template where a certain key in the JSON may or may not be defined, and I use a comparison filter, the body and else blocks are skipped.

Example JSON

{
  "myArray": [
    {
      "myOptionalCount": 0,
      "name": "Nothing here"
    },
    {
      "name": "Even less here"
    }
  ]
}

Example template

{#myArray}
  for {name}
  {@ne key=myOptionalCount value=0}
    myOptionalCount is not 0
  {:else}
    myOptionalCount is 0
  {/ne}
  {~n}
{/myArray}

Example output

for Nothing here myOptionalCount is 0
for Even less here

Expected output

for Nothing here myOptionalCount is 0
for Even less here myOptionalCount is not 0

[prashn64]

+1, this seems really broken right now.

It will probably just be a fix to the filter function.

[salazarm]

I would use

  {?myOptionalCount}
    myOptionalCount is not 0
  {:else}
    myOptionalCount is 0
  {/myOptionalCount}

[prashn64]

I'd say that is a work around, but it'd have to be more like this:

{?myOptionalCount}
  {@ne key=myOptionalCount value=0}
    myOptionalCount is not 0
  {:else}
    myOptionalCount is 0
  {/ne}
{:else}
  myOptionalCount is not 0
{/myOptionalCount}

The problem gets a lot worse the bigger the markup that would replace "myOptionalCount is not 0" gets.

[salazarm]

{?myOptionalCount}

evaluates to false when myOptionalCount is 0 so I don't think you need the @ne

[prashn64]

Good point. A better value to illustrate the bug would be one that is greater than 0.

[k2s]

example how to solve this problem with @js helper

[kate2753]

At first glance it seems reasonable to output {:else} block in this case. But there are few edge cases to keep in mind. What would be the expected output for comparison filters when both key and value are undefined? If they are both undefined, do we consider them equal? In JS undefined === undefined is true. In Dust that somehow feels wrong.

{@eq key=undefined value=undefined}
   bar!
{:else}
   baz
{/eq}

Another thing to keep in mind is that fixing this would be somewhat backward incompatible. If template relied on nothing being output previously, it would require a code fix (to execute comparison filter only when key is defined). Relying on this behavior does not seem like a good practice though and I'm in favor of fixing this. We should do a minor version bump with this fix though.

[sethkinast]

We should distinguish between cases where no key is specified (an error) and where key resolves to undefined (a possible outcome).