Allow template literal in JSXAttributeValue

[monsanto]

That is, allow stuff like <div className=myClass ${class1} ${class2} />, without having to wrap the string in {}.

[sebmarkbage]

Hm. That seems like a good idea but it's a bit of slippery slope. Currently the strings are treated as HTML attribute strings so they use escapes like & instead of \". Should these template strings be proper JS strings? I would assume so.

Should we also allow single quotes '? Are they JS strings or HTML strings? Is it weird that " and ' use different formats/escape characters?

What else do we need shorthands for? Numbers?

[zpao]

We do allow single quotes.

[sebmck]

Since JSX is an extension of ES it doesn't seem that far fetched to support template literals as an additional string type.

[RReverser]

Should we also allow single quotes '? Are they JS strings or HTML strings? Is it weird that " and ' use different formats/escape characters?

They are supported in both HTML and JSX.

Since JSX is an extension of ES it doesn't seem that far fetched to support template literals as an additional string type.

Agree - all of them are in the end string literals, and JSX adds only entity support (in single-/double-quoted strings it also extends them with multiline support, but in template literals we have that out of the box).

What else do we need shorthands for? Numbers?

Numbers are somewhat trickies case. On the other hand, we could probably support any JS atoms (array & object literals, numbers, single-/double-/back-quoted strings etc.) with no harm or ambiguity for JSX itself.

[sebmarkbage]

I would love to support all of them but object literals are ambiguous which complicates the story around what you can put in there. Since there is this special case.

Currently the special case for strings are only because they're in XML/HTML and treated as such.

On Jan 22, 2015, at 2:47 PM, Ingvar Stepanyan notifications@github.com wrote:

Should we also allow single quotes '? Are they JS strings or HTML strings? Is it weird that " and ' use different formats/escape characters?

They are supported in both HTML and JSX.

Since JSX is an extension of ES it doesn't seem that far fetched to support template literals as an additional string type.

Agree - all of them are in the end string literals, and JSX adds only entity support (in single-/double-quoted strings it also extends them with multiline support, but in template literals we have that out of the box).

What else do we need shorthands for? Numbers?

Numbers are somewhat trickies case. On the other hand, we could probably support any JS atoms (array & object literals, numbers, single-/double-/back-quoted strings etc.) with no harm or ambiguity for JSX itself.

—
Reply to this email directly or view it on GitHub.

[RReverser]

@sebmarkbage Oh, you're right about object literals, sorry.

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[gajus]

Has the consensus been reached regarding this feature?

The biggest reason for wanting template strings in JSXAttributeValue is consistency, e.g. I am using ESLint quotes rule to enforce template strings for all instances of string. Unfortunately, JSX attribute value declaration is an exception.

[monsanto]

My position hasn't changed after 9 months, would still like this feature.

[sebmarkbage]

I think the conclusion is that since these forms are currently semantically different in JSX parsers:

<input value="Foo &amp; Bar" /> // Foo & Bar
<input value={"Foo &amp; Bar"} /> // Foo &amp; Bar

We should keep it consistent which would mean that this would also be different:

<input value=`Foo &amp; Bar` /> // Foo & Bar
<input value={`Foo &amp; Bar`} /> // Foo &amp; Bar

It's unclear if going down this route would be a good idea since it opens up a whole new set of parsing semantics. We would need to define how to parse a template literal with mixed placeholders and HTML escaping / encoding rules. That seems very bad.

Therefore the conclusion is that we will only do this if we also drop the HTML encoding in string attributes which is discussed in #4 .

Consider this open but dependent on #4 .