Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

T.J. Crowder tj.crowder at farsightsoftware.com
Wed Jan 9 18:16:21 UTC 2019


On Wed, Jan 9, 2019 at 5:36 PM FERREIRA, ERIC B
<EF183V at att.com> wrote:
> I contend that adding `NoSubstitutionTemplate`s to the definition of
> `StringLiteral` will bring the benefit of allowing teams to
> completely opt to use only template strings instead of mixing quote
> marks, while having very little risk or downside, if any at all.

I've been toying with defaulting to template literals for some time. :-)

Interesting idea. Where specifically do you see benefits of this
change? The only places that immediately jump out to me are

* "use strict", mentioned in your linked article
* Quoted property names in object initializers (aka "object literals")
-- oddly not mentioned in that article (it mentions JSON, but not
object initializers)

That second one could be a bit of a footgun for people, who may trip
over this working:

```js
const obj = {`I have a space`: `bar`};
```

...but this failing:

```js
const obj = {`I have a space ${x}`: `bar`};
```

...because that's not a NoSubstitutionTemplate and so it needs to be a
computed property name.

Are there other places?

-- T.J. Crowder


More information about the es-discuss mailing list