-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow template literal in JSXAttributeValue #25
Comments
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 Should we also allow single quotes What else do we need shorthands for? Numbers? |
We do allow single quotes. |
Since JSX is an extension of ES it doesn't seem that far fetched to support template literals as an additional string type. |
They are supported in both HTML and JSX.
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).
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. |
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.
|
@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. |
Has the consensus been reached regarding this feature? The biggest reason for wanting template strings in |
My position hasn't changed after 9 months, would still like this feature. |
I think the conclusion is that since these forms are currently semantically different in JSX parsers: <input value="Foo & Bar" /> // Foo & Bar
<input value={"Foo & Bar"} /> // Foo & Bar We should keep it consistent which would mean that this would also be different: <input value=`Foo & Bar` /> // Foo & Bar
<input value={`Foo & Bar`} /> // Foo & 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 . |
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. |
I don't get it. In Javascript we have 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.
Why not just add Support for custom tags can be skipped for now and they are a lot less common for properties. |
Hello there, 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? |
consider this:
which means: h('el', { attr: t`a${b}c` }) this may give user a chance to handle substitutions (e. g. strip |
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 . |
That is, allow stuff like
<div className=
myClass ${class1} ${class2}/>
, without having to wrap the string in{}
.The text was updated successfully, but these errors were encountered: