Skip to content


Provide a filter for inserting value string #204

rragan opened this Issue · 3 comments

2 participants


Today dust only renders a string once so if I have a data value in my JSON like:

Copyright LinkedIn {year}

and I happen to have a value there for year also, the output will still be "Copyright LinkedIn {year}". This seems like a good thing in general because extra passes over the rendered content would slow down dust for rare cases.

I would like to see a new filter: {data | eb} where eb stands for "Expand Braces" that would do the following:

  • Find each brace-delimited string in "data" (e.g. {year} )
  • Do a get operation on the "year"name
  • Replace the {year} with the get result (or leave the {year} intact if get found nothing - or alternatively replace it with an empty string.

This would allow users to achieve second level value insertion with no further cost in general rendering time. Note that the same filter can be applied more than once so triple escaping could be done by adding a second eb.

This requires a minor internal change in the dust code in
Chunk.prototype.reference = function(elem, context, auto, filters) {
on the following line where I've added passing context to the filter so they can do the get (or any other useful action requiring context)
return this.write(dust.filter(elem, auto, filters, context));

I've played with the following implementation of "eb" to explore the idea:

eb: function(value, context) { 
   var phs = value.match(/\{([0-9a-zA-Z]+?)\}/g);
    for (var i=0; i<phs.length;i++) {
     var pn = phs[i].substr(1).replace("}","");
     var pval = context.get(pn);
     var rx = new RegExp("{" + pn + "}", "g");
     value = value.replace(rx,pval);
    return value;

why not make this a helper? ( looks like formatting to me than filtering , there is a subtle difference )

second, @jimmyhchan is creating a way to add extensions to filters and helpers without changing th core dust js size.

so in this way, other teams do not feel the pain of downloading more than the core dust.


Yes it could have been a helper but this exploration was in response to comments that our content helpers were too verbose: {@content $key="pathToContent" /} when there is no placeholder substitution and {@content $key="pathToContent" name="{valueFromModel} /}

The exploration showed the possibility of using:

{pathToContent} and

which are more concise and it is still possible to use the result to pass as a param which is not the case with helpers.


both helpers and filters should be made extendable and we can have contributed helpers and contributed filters as separate repos.

Addressed as part of:

@bfui bfui pushed a commit to bfui/dustjs that referenced this issue
Michael Allen #204 add context to dust.filters 4f9d8f8
@bfui bfui pushed a commit to bfui/dustjs that referenced this issue
Michael Allen #204: add context to filter args d9e3789
@sethkinast sethkinast added a commit to sethkinast/dustjs that referenced this issue
@sethkinast sethkinast Pass the current context to filters.
Closes #394
Closes #204
@sethkinast sethkinast closed this in #673
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.