Discuss
  • Add support for arbitrary code inside template tags without the 'do' keyword

Add support for arbitrary code inside template tags without the 'do' keyword

# Manuel Di Iorio (9 years ago)

I asked around and somebody said that there will be the possibility to execute arbitrary code inside the template tags, using the 'do' keyword in this example way:

`Hello ${ do if (a == 2) {
    return 'world';
} }`

Is there the possibility in future to implement that feature without the keyword? What is the plan (read 'estimated date') for the rollout of this feature ?

The idea to develop in native way a good templating engine is exciting and I'm looking forward for its complete implementation :)

# Caitlin Potter (9 years ago)

Do-Expressions are still floating around Stage 0, there’s no guarantee that they will be incorporated into the language.

The feature is implemented in v8 behind a flag, and can be used in Chrome Canary by launching the browser with —js-flags=“—harmony-do-expressions”, which would enable you to try it out.

INTERMISSION — Slightly more on-topic portion of post follows after a short coffee break

However, to answer your question, you can implement an immediately-invoked-function-expression, like this:

`Hello ${_ => {
  if (a == 2) {
    console.log(‘world’);
  }
}()}`;

So this wouldn’t depend on the Do-Expressions proposal, and wouldn’t require a keyword per se, although you’d still have some extra tokens making things a bit harder to read.

It’s unlikely that the grammar would be changed to accommodate this use case, given that people are using template literals already, and the use-case is already supported by other means.

# Michael Ficarra (9 years ago)

Watch your precedence, Caitlin. You'll need to wrap that arrow in parentheses like so:

`Hello ${(_ => {
  if (a == 2) {
    console.log(‘world’);
  }
})()}`;

Michael

# Manuel Di Iorio (9 years ago)

Thanks Caitlin for the workaround ;)

However, as you can note, to write the following is not that much praticable and readable:

${()=>{
  //code here
}()}

At least, the *do *keyword will improve the situation with i.e:

${do {
  //code here
}}

Hope to see news about the 'do' keyword adoption or something even better in the early future! :D

# /#!/JoePea (9 years ago)

If it's any consolation, you can currently use Babel (f.e with Webpack, Browserify, etc) to compile do-expressions (babeljs.io/docs/plugins/syntax-do-expressions), so you can use the syntax right now.

# Caitlin Potter (9 years ago)

Watch your precedence, Caitlin. You'll need to wrap that arrow in parentheses like so:

Yes, I guess arrow functions aren’t a PrimaryExpression — doesn’t really matter, though

# Bob Myers (9 years ago)

The idea to develop in native way a good templating engine is exciting

and I'm looking forward for its complete implementation :)

This topic arose in an earlier thread that I'm too lazy to track down. Some insane person from Microsoft? actually showed us how to write ifs and everything using horribly nested template strings.

Bottom line, template strings, with or without do, which is both unnecessary and would break everything, are not a good starting point for writing a templating engine. I'd definitely take a different approach.

Bob

# Manuel Di Iorio (9 years ago)

Yes Bob, after a personal testing with a complete template engine using the ES6 template strings, I realized that their use (in my use case, of course) is slowest than the approach that I'm using right now (like the Underscore template). Thanks everyone :)

# /#!/JoePea (9 years ago)

The thing with template strings is that they are used at runtime. This could be slow if we're compiling things at runtime all the time, whereas a server-side templating solution might lead JavaScript functions compiled from templates (like in the case with Meteor Blaze Spacebars or React JSX), which can be faster at runtime.

What are template strings good for besides the obvious benefit that they make things like

var str = "llo"
console.log(`he${str} world!`)

easier to read than

var str = "llo"
console.log('he'+'str'+' world!')

?

Maybe writing regexes can be nicer with template strings? I gave it a try at npmjs.com/regexr.

# Alexander Jones (9 years ago)

The two code samples you posted are equivalent (modulo the obvious mistake). AFAIU there is still only a single parsing pass for template strings.

# Isiah Meadows (9 years ago)

A use I thought up (although I got lazy and abandoned it later) was an exec template tag, for executing commands. Or, and this just came off the to of my head, you could use it as a vdom library as almost like a Lisp reader macro:

n`.form-ctrl`(
  n`input#input`("input"),
  n`a[href="/submit.html"]`("Submit"))
# /#!/JoePea (9 years ago)

modulo the obvious mistake

Oops. x]

you could use it as a vdom library as almost like a Lisp reader macro:

That would be interesting. There's still lots of runtime processing though. Maybe a build-time tool can also optimize it though, but if it happens to be executed at runtime it'll just work. Here's a JSX-like concept, let's call it 'xjs' for sake of argument:

let style = {background: 'turquoise'}
let content = xjs`<p>hello</p>`

let el = xjs`
  <div style=${styleObject}>
    ${content}
  </div>
`

It could be compiled statically as well as have a runtime template-tag implementation.

# Isiah Meadows (9 years ago)

Problem is: your idea has already been tried and found to be pretty slow. React devs did briefly consider this, but found that it had fundamental speed limitations. And precompilation is already happening with existing templates, even though building them normally is still cheap to do.

facebook.github.io/jsx/#why

# Isiah Meadows (9 years ago)

That link details other reasons, such as tooling.

# /#!/JoePea (9 years ago)

Interesting!

# Shahar Or (9 years ago)

On Thu, Jan 14, 2016, 01:11 Isiah Meadows <isiahmeadows at gmail.com> wrote:

Problem is: your idea has already been tried and found to be pretty slow. React devs did briefly consider this, but found that it had fundamental speed limitations. And precompilation is already happening with existing templates, even though building them normally is still cheap to do.

facebook.github.io/jsx/#, facebook.github.io/jsx/#why-not-template-literals why-not-template-literals

Substack recently released a package that may contribute to this discussion: substack/hyperx