linkedinattic / dustjs-helpers Goto Github PK

{key: 10}

{@lt key="{key}" value="3"}{key} less than 3{/lt}

This will output "10 less than 3"

If I change it to 2 it works correctly or if I change it to 8, but anything beyond 9 will always pass.

... updating issue #16 to ... what is the best way to check type given there are so many ways to get at a variable?

Ideally, references and inline literals should return the same type. That way when we pass type in @eq it should behave consistently.
examples:

{
  varString: "abc",
  varTrue : true,
  varFalse : false,
  varOne : 1
}

/* these should all be the same */
{@eq key="abc" value="abc" }
{@eq key=varString value="abc" }
{@eq key="{varString}" value="abc" }
{@eq key="abc" value=varString type="string" }


/* As should these */
{@eq key=false value=false }
{@eq key=varFalse value=false }
{@eq key="{varFalse}" value=false }
{@eq key="{varFalse}" value="" type="boolean" }

Types of parameter values:

• value = "simple string"
• value = "{singleVar}"
• value = "{interpolated} string"
• value = "{ref1} {ref2}"
• value = referenceFoo
• value = referenceFunc
• value = 12345
• value = true, value=false
• value = undefined, value=null, value=NaN

Issues we want to address:

• dust.helper.tap currently internally changes types to strings. Should we use chunk.tap instead?
• what's a good migration path away from @if which requires the current 'dust.helper.tap` behavior.
• If we go to chunk.tap how do we resolve interpolated strings e.g. paramKey="{var1} interp {var2}"?
• chunk.tap behavior for "missing data" what does it do?

With 0.12 support being added (#112) we should consider dropping support for 0.8. This is very low priority given that things still work in Travis.

Putting this out there for discussion and early warning that 0.8 support will be removed (at some point).

We have strongly discouraged the use of the if helper. Can we formally deprecate and remove it?

Here are the datas:

{
  "selecteddog": "Bill", // works
  "selected": {
    "dog": "Bill"        // selected.dog doesn't work
  },
  "dogs": ["Rex", "Bill", "Brutus"]
}

Here is the template:

<select name="dogs">
  {#dogs}
  <option value="{.}"{@eq key=. value=selecteddog} selected="selected"{/eq}>{.}</option>
  {/dogs}
</select>

This is ok and compiles to:

<select name="dogs">
  <option value="Rex">Rex</option>
  <option value="Bill" selected="selected">Bill</option>
  <option value="Brutus">Brutus</option>
</select>

Now if I get the @eq value from selected.dog (see the dot):

{@eq key=. value=selected.dog} selected="selected"{/eq}

it does not work anymore:

<select name="dogs">
  <option value="Rex">Rex</option>
  <option value="Bill">Bill</option>
  <option value="Brutus">Brutus</option>
</select>

Seems like selected.dog is not "resolved"...

fix the css, code indentation and the functionality

Every library that has dusjs-helpers as dependency and is tested via mocha is failing the tests.

dustjs-helpers manipulates the global namespace (dust = require('dustjs-helpers');) thus mocha criticizes the global leak.

hello,

I have this model :

{
    "current": false
}

when i try to apply this dust template the output is empty :

{#current}
  {@select key="{current}"}
    {@eq value=false}
      bbbbb
    {/eq}
    {@default}
      aaaaa
    {/default}
  {/select}
{/current}

If i simply add quotes to /false/ it works...

{
"current": "false"
}

and the template :

{@eq value="false"}

output --> bbbbb

Is there something wrong with my code ? Does "select" support "pure" boolean types (boolean recorded with no quotes) ?

thanks for your input

It looks like the package.json has been updated to correctly reflect updated dustjs-linkedin version. However, what is published on NPM does not match what is on github with the same version in the package.

Could we get a NPM patch version bump? This would help fix peerDependency issues I've seen with trying to update dustjs versions on Kraken modules (adaro and makara).

{@eq key=typestring value="foo"}

yes it is foo!

{/eq}

{@eq key="{typestring}" value="foo"}

yes it is foo!

{/eq}

{
"typestring" : "foo" ,
"typeint" : 1 ,
"typeboolean" : true

}

Hello,

is there any reason to not have bower support (bower.json) like the main project (dustjs-linkedin)?

Regards,
Paulo

...does not work, at least not in a commonJs environment as the bootstrapping function relies on a global available dust instance.

The npm package is behind the repo, e.g. peerDependency on dustjs, which complicates deployments for some folks.

I've started using dustjs for a project, and I need to be able to loop N times.

An example of this might be a product has a rating of N. Loop N times creating stars.

Is there a reason there isn't already a helper for this, as it seems like a basic piece of logic? The reason I'm asking is because I don't want to go against the core principles of dust.

If there is no reason, should I create a fork and a PR for a helper?

Hi,

Sorry if this has already been answered, but cannot find documentation on how to write a custom dust.js helper...

I think it should be defined under dust.helpers with a function like function (chunk, context, bodies, params) {} but is there any documentation or good examples about these params?

Thank you

We don't want to define every vaguely useful filter and helper in the core dust library. Some sites will provide extensions of their own for helpers and filters but even then users may find an ad-hoc need that is not general enough to be site-supplied.

I propose a new helper {@extend [filter|helper]=name} to let users provide their own filter or helper as needed. Here is a sample of doing each:

{@extend filter="my"}
function myfilter(string) {return  "***" + string + "***"; };
{/extend}
{@extend  helper="assist"}
function assist (chk, ctx, bodies, params) {
        var key = dust.helpers.tap(params.key, chk, ctx);
        return chk.write(key + key);
}
{/extend}
FILTERED:{str| my}
{~n}
HELPED: {@assist key="do" /}

The code for this helper is:

dust.helpers.extend = function (chk, ctx, bodies, params) {
        var key;
        var saveData = chk.data,
          result;

        chk.data = [];
        var result =  bodies.block(chk, ctx).data.join("");
        chk.data = saveData;
        if (params.filter) {
                key = dust.helpers.tap(params.filter, chk, ctx);
                dust.filters[key] = eval("false||"+result);
        } else if (params.helper) {
                key = dust.helpers.tap(params.helper, chk, ctx);
                dust.helpers[key] = eval("false||"+result);
        }
        return chk.write("");
};

I think it would be more modular if the helpers were in separate modules and brought in as-needed instead of bringing them all in at once.

Here is some background as to why I wanted to pursue this.

I made a branch to track my progress. Any feedback would be appreciated.

most helpers log to console when certain conditions aren't met.
though this is fine for development it makes no sense for production and it should be possible to suppress these console messages.

i'd be happy to devise a PR that accomplishes exactly this, if someone is interested.

Apparently related to #50.

In a @select scope, when searching for a key in current context with '.' prefix, the key is not found.

Affected version: dustjs v2.3.4, dustjs-helpers v1.2.0

Workaround: using a standalone @eq

Example:

DUST

{#bar}
1.{@select key=jar}{@eq value="JAR"}'{bam}'{/eq}{/select} [OK]{~n}
2.{@select key=jar}{@eq value="JAR"}'{.baz}'{/eq}{/select}    [KO!] <==== expected: 'BAZ'{~n}
3.{@eq key=jar value="JAR"}'{.baz}'{/eq} [OK] 
{/bar}

JSON

{
 "foo":"FOO",
 "bam":"BAM",
 "bar": {
    "baz": "BAZ",
    "jar": "JAR",
  }
}

When using @select, dot paths no longer work inside @eq branches.

This jsfiddle concisely demonstrates: http://jsfiddle.net/KdZMc/

data:

{path:'/console'}

usage:

{@eq key="{path}" value="/console"} ok {/eq}

I'm confused by this, I have readed this doc, but it doesn't show how to compare string : https://github.com/linkedin/dustjs/wiki/Dust-Tutorial#Helpers.

Could anybody tell me how to do that?
Thanks!

Currently, the dust-helper.js implementation will blow away any existing dust.helpers the user may have created. Could the code be a bit more tolerant and add the standard ones to an existing dust.helpers if it already exists.

I guess one could assert that the dependency order needs to be gotten correct and then this is not an issue but it adds another trap people can fall into.

Hello,

is it possible to have support of this library on jamjs.

The same request has been open on the main dustjs repository.

linkedin/dustjs#212 (comment)

Thanks

• security
• bad performance

When passing a key to @select, @eq et al and when the key is 0 (not a string, a number), the helper crashes:

var ctx = { a: [] };
dust.compileFn('{@eq key=a.length value=0}yes{:else}no{/eq}', 'tmpl');
dust.render('tmpl', ctx, function(err, str) {
  return console.log(str);
});

outputs:
ERROR: No key specified for filter and no key found in context from select statement

Note that everything works fine the moment you insert an element into the array (and raise to value=1 if you want the match to succeed).

If there's a reason why 0 should get a special handling then it escapes me. In particular in context of {?a.length} matching as true (since it exists) even if the length is 0, this is the only other reasonable way to test for an empty array is {@gt key=a.length value=0} which, however, fails.

The math helper returns a decimal when an integer is expected when certain arithmetic operations are performed (e.g. 100*.57)

Is there any documentation for dustjs-helpers with express?

It would nice if the dust.helpers.tap method returned the original array or object if it is passed in as an argument. Currently if I do this, it will return an array as a CSV or "[object Object]" respectively.

More concretely, I am trying to build a helper that takes an in object during initialization and outputs a value by indices. An object can be of any dimension.

desired template

{@matrix indices="{indices}" /}

helper setup

dust.helpers["array"] = function(chunk, context, bodies, params, table) {
    var indices = dust.helpers.tap(params.indices, chunk, context);
    // return value by traversing 'table' according to the indices provided
};
dust.helpers["matrix"] = dust.helpers["array"].curry( /* json object */ );

usage

// this currently won't work because dust.helpers.tap turns "indices" into a CSV
dust.render("matrix", {"indices": ["0", "1"]}, function(err, out) { /* etc */ });

Need to downgrade to 1.1.x before it will work.

Sample app: https://github.com/kethinov/dustjs-helpers-issue-84

Issue #33 was well along the path to allowing user helpers to be added to the dust object regardless of the load order of dust-helpers. Currently, they can only be safely added after dust and dust-helpers are loaded. Changes to dust and dust-helpers are needed to mitigate this load order issue.

Am I able to pass in an array as inline parameter to a partial? I'd like to specify a list of options for a select partial within the template itself rather than adding it to my data object in my backbone view.

With version 1.2 requiring helpers on the server side adds no helpers to the dust object. It does work fine on the client side.

dust = require('dustjs-linkedin')
require('dustjs-helpers')
console.log dust.helpers

This outputs {} when used on the server side only. 1.1.x will output the helpers in the object.

I am migrating some of my templates to Dust and I have plenty formatters in JavaScript I need to use. I did not found a good way how to use that formatters in Dust and I found for example this StackOverflow question.

So I wrote experimental all-in-one helper. It works for my needs.

I added it to dust-motes fork because of better code separation.

I would be very happy to hear your opinion if this helper fits the Dust ecosystem, what changes and additions you think should be done in my first version.

Example code:

Dust:

{@select key=lix_key}
  {@eq value="D"}
    {emails|js}
    {@contextDump key="current" to="console"/}
    {#emails.suggestedProfiles}
      {name}  
    {/emails.suggestedProfiles}
  {/eq}
...
{/select}

When trying to iterate using {#} within a {@select} block, the context appears to be lost. The iteration simply does not happen, even though the JSON object exists and is valid.
The object ({emails} in the example) when printed is perfectly fine and valid.
However when the current context is dumped within one of the {@eq} blocks, all that is outputted is:

JSON:

{
  "isSelect": true,
  "isResolved": true,
  "selectKey": "D"
}

This leads me to believe the current context is lost and thus the iteration doesn't happen. Removing the {@select} block makes everything work properly.

Hi,

Is it possible to test if $key in the below code is true?

{@iterate key=result.variables}
{@eq key="{$type}" value="boolean"}
          <select name="{$key}" class="form-control">
           <option value>false</option>
           <option value {?$key}selected{/$key}>true</option>
          </select>
{/eq}
{/iterate} 

{?$key}selected{/$key} doesn't seem to work.

Is there a way to test if key is true?

I see I can use @sep to do things for anything BUT the last row, but how about the opposite? I know you guys are hesitant to put new things in the core code, but if anybody has a custom one I'd love to see it, otherwise I'll dig around in the @sep and see if i can flip it.

I see references to jsControl helper. http://www.slideshare.net/veenabs/curious-case-of-dust Slide 26 and 29. I would like to know what it is and when and where to use. And I dont find the implementation of it in https://github.com/linkedin/dustjs-helpers/blob/master/lib/dust-helpers.js

I needed this case:

{@size key="myObj"}
  {@gt value=1}
    More than One!
  {:else}
    Less than One!
  {/gt}
{/size}

I wrote a wrapper helper looks like this:

dust.helpers.sizeOf = function(chunk, context, bodies, params) {
        var value = this.size(chunk, context, bodies, params);
        return (bodies && bodies.block) ? chunk.render(bodies.block, context.push({ isSelect: true, isResolved: false, selectKey: value })) : value;
    };

And used {@sizeOf ... /} instead of {@size ... /}
I'm just wondering if we can do this inside size helper, to act like @math and @select helpers ?

This issue is that we only co-erced to a given type for expectedValue

The issue is fixed with co-ercing both key and value to the same type

Most often the comparisons for lt. lte. gt. gte is for numerics.

today the select helper has type=string as default, make type=number as default

I have data set like that:
[{"val": false}, {"val": true}]

And template:
{#.}
{@eq key=val value=false}
FALSE
{:else}
NULL
{/eq}
{/.}

Value=false is compiled to: "value": ctx.get(["false"], false), not to false. I think is it inncorect. For other base types like integers we get right: "value": 1.

It has been fixed with correct handling of inputs

linkedin/dustjs#129

@smfoote
https://github.com/github/gitignore/blob/master/Global/vim.gitignore
https://github.com/linkedin/dustjs-helpers/tree/master/lib/.dust-helpers.js.swp

Esp for mod ( does negatives work as expected )

dustjs-linkedin 2.5 was released today.
Since the "new" way of doing things now is to use caret instead of tildes in package.json files,
this causes a slight peer dependency error for those using the following

{
"dustjs-helpers": "^1.3",
"dustjs-linkedin": "^2.4.0"
}

Given that dustjs-helpers uses

  peerDependencies: { 'dustjs-linkedin': '~2.4.0' },

If I write {@SiZe key="{str} /}, the value output is a constant regardless of the length of the string in str. That is because a {key} value results in a function being passed to the helper and it computes the length of that function converted to a string -- a particularly useless behavior.

I would suggest size be changed to run tap on any key input that is a function and compute the length of the result.

What say you who built the size helper? Is this a bug or an oversight?

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