dustjs
dustjs copied to clipboard
Add a filter support to not suppress the undefined and false values in dust references ( may extend it to lists as well )
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 : https://github.com/linkedin/dustjs/issues/135
Similar issue that was closed https://github.com/linkedin/dustjs/issues/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?
Is this resolved by the debug statements added?
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