Allow template literal in JSXAttributeValue about jsx

[srittau]

Since it's been a while since the last comment on this, I'd like to voice my support for this. I fairly often have constructs like this:

<div className={`${foo ? "foo" : "bar"} stuff`}/>

Reducing this to:

<div className=`${foo ? "foo" : "bar"} stuff`/>

would help to reduce the line noise a bit. I think the former and the latter form should be equivalent, everything in between the backticks should be valid JavaScript code. I don't think it is a good idea to special-case not having the braces around it.

[sebmck]

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

[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 .

[EECOLOR]

I don't get it. In Javascript we have ' and " which we can both use in jsx. Now we have ` which is just another way to create a string. We should be able to use it in jsx.

Of course I would like jsx to support all javascript primitives, but that will put a lot more strain on the parser and I think it should be considered another issue entirely.

prop='...' vs prop={'...'} can behave the same for ` and "

Why not just add ` with the same semantics as ' and "?

Support for custom tags can be skipped for now and they are a lot less common for properties.

[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?

[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.

[monsanto]

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

[zpao]

We do allow single quotes.

[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 [email protected] 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.

[valoricDe]

Hello there,
I would like to come back to the question of @gajus in babel/babel#2309.

Is it possible to expand supported syntax via a parser plugin? Then anyone which doesn't use html entities in attributes - why would you - can include the plugin for their project or not.

Following https://lihautan.com/step-by-step-guide-for-writing-a-babel-transformation/ or https://lihautan.com/creating-custom-javascript-syntax-with-babel/ it looks like it is possible or do we need to consider special JSX handling?

[LongTengDao]

consider this:

/** @jsx h */
/** @jsxTag t */
<el attr=`a${b}c` />

which means:

h('el', { attr: t`a${b}c` })

this may give user a chance to handle substitutions

(e. g. strip boolean null undefined substitutions, like {b} in children)

[tolmasky]

Going off of the comments in the Babel thread, I've submitted a PR that hopefully address the HTML encoding concerns, and also tries to explain this a bit more in the spec itself: #132 .