Typescript: Backtick string template literal in TSX without curly brackets

Created on 21 Sep 2020  路  8Comments  路  Source: microsoft/TypeScript

Search Terms

backtick string template literal react tsx

Suggestion

Curly brackets wrapping around quotes is visually noisy. It would be nice to have string interpolation without having to use curly brackets.

Use Cases

  • String interpolation in attribute names

Examples

<Link href=`https://www.example.com/{foo}/{bar}`>Link</Link>

Checklist

My suggestion meets these guidelines:

  • [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • [x] This wouldn't change the runtime behavior of existing JavaScript code
  • [x] This could be implemented without emitting different JS based on the types of the expressions
  • [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • [x] This feature would agree with the rest of TypeScript's Design Goals.
External

Most helpful comment

All 8 comments

You should probably create a TC39 proposal for this, because this wouldn't be legal JSX.

@MartinJohns JSX is not plain JavaScript. I don't think TC39 would care.

Good point, I wasn't aware of that. But there should still be special consideration for "jsx": "preserve", because I doubt any other tooling will support this.

But there should still be special consideration for "jsx": "preserve"

"jsx": "preserve" does not prevent es5 transpilation right?

It does not prevent ES5 translation.

// Source:
<Link href={`https://www.example.com/${foo}/${bar}`}>My Link</Link>;

// ES5 result:
<Link href={"https://www.example.com/" + foo + "/" + bar}>My Link</Link>;

// ES2015 result:
<Link href={`https://www.example.com/${foo}/${bar}`}>My Link</Link>;

To be fair, I understand the curly braces can be annoying (and a distraction), but the difference is really negligible:

<Link href={`https://www.example.com/${foo}/${bar}`}>My Link</Link>;
<Link href=`https://www.example.com/${foo}/${bar}`>My Link</Link>;

We don't want to create a variant of a variant - the linked issue above should be resolved first, at which point we can trivially take up a fix on our side.

This issue has been marked as 'External' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Was this page helpful?
0 / 5 - 0 ratings