Brackets in template literals

[mikeal]

So, the current standardjs config enforces:

let init = () => {}
let text = 'asdf'
funky`
${init}
<div>
  <span>${text}</span>
  <span>${o => o.attr || 'default'}</span>
</div>
`

And does not allow:

let init = () => {}
let text = 'asdf'
funky`
${ init }
<div>
  <span>${ text }</span>
  <span>${ o => o.attr || 'default' }</span>
</div>
`

I find the latter much more readable and am surprised it is being enforced this way.

Is this particular use case intended to be enforced this way or is this just brackets being enforced inside of template literals the same way they are outside because of a broader setting?

[mikeal]

@feross ^^

[LinusU]

I personally prefer there to be only one way of doing things, and, perhaps unfortunately, we already enforce it to be without spaces. Switching now could potentially be painful for our users...

[mikeal]

This just isn't consistent with other rules regarding brackets. For instance, all of these are allowed:

let test = { test: 'asdf' }
let testfunc = () => { 'asdf' }

In fact, the following is explicitly NOT ALLOWED.

let testfunc = () => {'asdf'}

Which is the exact opposite of the enforcement of brackets in template literals.

As far as switching costs is concerned, template literals are a relatively new feature and switching now in order to make it more consistent shouldn't be too costly.

Because of the way the literals work any whitespace before and after the brackets ends up being real whitespace in the string. In practice this means that shoving all the characters inside the replacement into the brackets ends up being really noisy and visually confusing.

I'm using template literals enough at this point that I'm considering getting off of standardjs if this ends up being what is enforced long term. It just doesn't make any sense and is out of alignment with the enforcement of white space in other places.

[feross]

Point taken. We do need to make some decisions to make things more consistent in v9.