Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Add a filter support to not suppress the undefined and false values in dust references ( may extend it to lists as well ) #138

vybs opened this Issue · 6 comments

4 participants


In some cases, we would like not to fail gracefully for missing values in the JSON, mostly for validating certain data exists at all times.

Even though this validation can be done on the "context", it is convenient to have a special filter to "enforce" that this value should always exist in the JSON

The only code to be modified is

 Chunk.prototype.reference = function(elem, context, auto, filters) {
  if (typeof elem === "function") {
    elem = elem(this, context, null, {auto: auto, filters: filters});
    if (elem instanceof Chunk) {
      return elem;
  if (!dust.isEmpty(elem)) {
    return this.write(dust.filter(elem, auto, filters));
  } else {
    return this;

Related to : #135


Similar issue that was closed #45

Should we be able to filter falsy values.
the :else block is sufficient but only if you content with how dust determines truthiness.


This has languished for a year. Is it still important enough to keep around as an open issue or have people found solutions?


No, the debug statements would not fix this, even if we added a check for it.

I think this is still a valid issue. The filter should decide if it can use an undefined value.


What exact behavior are you looking for? Do you want a mechanism to fail the template if the data is not present or are you looking for way to default a value when it is not present, for example.

I had a variant of this earlier today where the user wanted to fail the template when a partial did not get passed a parameter (tantmount to it not being in context since right now you can't tell them apart). I tried adding an @abort helper that did a throw "message" but in non-debug mode this does nothing. Our current model of suppressing/console logging all errors does well to soldier on when there are problems but does not provide a way to fail when things are seriously wrong.


Might be related to #381. A helper instead of a filter sounds better.

@rragan the abort helper that throws is probably being eaten by the try/catch added recently #381.

{?mightExist}{foo}{:else}{@log message="we should fix this it should be working"/}{/mightExist} and {?shouldStop}{foo}{:else}{@abort message="this should be working"/}{/mightExist} sounds like it would be useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.