Quasi-literals for templating?

Axel Rauschmayer axel at rauschma.de
Wed Jun 15 08:15:12 PDT 2011


> If we relax this position back towards Expression, then, if you want to pass such pairs, you could do so:
> 
>     foo`...${ {bar} }...${ {baz} }...`
> 
> Recall that {bar} will be syntactic sugar for {bar: bar}. So this would expand to
> 
>     foo(literalPartsRecord, {bar: bar}, {baz: baz})


Ah, nice.

However, wouldn’t a different data structure be better for handlers? Zipping arrays together feels like unnecessary work.

For example:
quasiHandlerName`quasiLiteralPart1 ${quasiSubstitution} quasiLiteralPart2`
=> quasiHandlerName([
    { raw: "quasiLiteralPart1 ", escaped: "quasiLiteralPart1 " },
    { value: ... },
    { raw: " quasiLiteralPart2", escaped: " quasiLiteralPart2" },
]);

The above example would work as follows (right?). This keeps the values as they are, instead of turning them into strings ("{bar: bar}" and "{baz: baz}" seem to be strings).
var bar = "abc";
var baz = 123;
foo`${{bar}}${{baz}}`
=> foo([
    { raw: "", escaped: "" }, // not really necessary, any more
    { value: "abc", key: "bar" },
    { raw: "", escaped: "" }, // not really necessary, any more 
    { value: 123, key: "baz" },
    { raw: "", escaped: "" } // not really necessary, any more
]);


Alternatively, one could have two different types, one for literal parts, one for substitutions.


-- 
Dr. Axel Rauschmayer

axel at rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110615/30aacbec/attachment.html>


More information about the es-discuss mailing list