@eq helper and how are we suppose to check type? about dustjs-helpers HOT 5 CLOSED

{@eq value="1"} - value is a constant

{@eq value={one}} - not valid grammar

{@eq value="{one}"} - added tests ( seems to work ) but may be not all cases

{@eq value=one} - this has unit tests too. ( but need to validate it works in all cases )

from dustjs-helpers.

Here are the test cases I was looking at

--- a/test/jasmine-test/spec/helpersTests.js
+++ b/test/jasmine-test/spec/helpersTests.js
@@ -189,6 +189,20 @@ var helpersTests = [
     message: "eq helper matching string case"
   },
   {
+    name:     "eq helper for boolean true value",
+    source:   "{@eq key=\"{foo}\" type=\"boolean\" value=\"false\"}true is false {:else} true is not false{/eq}",
+    context:  {foo: true},
+    expected: "true is not false",
+    message: "eq helper for boolean true value"
+  },
+  {
+    name:     "eq helper for boolean false value",
+    source:   "{@eq key=\"{foo}\" type=\"boolean\" value=\"false\"}false is false {:else} false is not false{/eq}",
+    context:  {foo: false},
+    expected: "false is false",
+    message: "eq helper for boolean false value"
+  },
+  {
     name:     "eq helper non matching string case",
     source:   "{@eq key=\"foo\" value=\"bar\"}equal{:else}bar{/eq}",
     context:  {},

The coerce function was modified to work better but seems specific to string inputs

function coerce (value, type, context) {
  if (value) {
    switch (type || typeof(value)) {
      case 'number': return +value;
      case 'string': return String(value);
      case 'boolean': {
        value = (value === 'false' ? false : value);     
        return Boolean(value);
      }
      case 'date': return new Date(value);
      case 'context': return context.get(value);
    }
  }

  return value;
}

Seems type coercing for things that are not strings are difficult because tap on references will return strings, whereas tap on numbers/boolean/scalars will just return it. We can't really tell if something will be a reference or not when we call tap.

from dustjs-helpers.

@jimmyhchan

We have to fix this use case "We can't really tell if something will be a reference or not when we call tap."

from dustjs-helpers.

@jimmyhchan , here is the how the tap works ( same as chunk.render )

// Utility helping to resolve dust references in the given chunk
// uses the Chunk.render method to resolve value
/*
Reference resolution rules:
if value exists in JSON:
"" or '' will evaluate to false, boolean false, null, or undefined will evaluate to false,
numeric 0 evaluates to true, so does, string "0", string "null", string "undefined" and string "false".
Also note that empty array -> [] is evaluated to false and empty object -> {} and non-empty object are evaluated to true

if value does not exist in JSON and the input is a single reference: {x}
dust render emits empty string, and we then return false

if values does not exist in JSON and the input is a chain of references : {x} < {y}
dust render emits < and we return the partial output

*/
"tap": function( input, chunk, context ){
// return given input if there is no dust reference to resolve
var output = input;
// dust compiles a string/reference such as {foo} to function,
if( typeof input === "function"){
// just a plain function (a.k.a anonymous functions) in the context, not a dust body function created by the dust compiler
if( input.isFunction === true ){
output = input();
} else {
output = '';
chunk.tap(function(data){
output += data;
return '';
}).render(input, context).untap();
if( output === '' ){
output = false;
}
}
}
return output;
},

from dustjs-helpers.

After talking to Jimmy, we identified the root cause is "tap" returns a string always ( thus modifying the type of the input passed in in many cases )

the reason it returns string : tap supports interpolated strings such as {A}_{B} and hence we need to coerce the final output to string.

from dustjs-helpers.