Proposal: using ! prefix on JSX attributes to set them to false

[yuval-gilboa]

Suggestion

🔍 Search Terms

JSX, TSX, JSXElement, JSXAttribute, JSXAttributeName, markup, templates

✅ Viability Checklist

My suggestion meets these guidelines:

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

⭐ Suggestion

According to current syntax, a JSX attribute without an initializer is set to boolean true.
However, there is no such shortcut equivalent for initializing an attribute for false so in this case the full form must be used explicitly.

My proposal is to allow an ! prefix before the attribute name as shortcut for false.
This syntax extension is backward compatible with current grammar and can be added without impact on any existing JSX codebase.

I've opened corresponding feature request on facebook's draft JSX specification - see facebook/jsx#134, but i'm not sure whether TS follows that specification or not since it is not officially part of the EcmaScript specification.

📃 Motivating Example

• <MyComp visible/> is equivalent today to <MyComp visible={true} />
• <MyComp !visible /> will become equivalent to <MyComp visible={false} />

💻 Use Cases

This is quite a common case that is needed for any JSX attributes whose default value is defined as true. It helps reduce unnecessary clutter and simplify JSX expressions.

[MartinJohns]

You should post your proposal at: https://github.com/facebook/jsx - TypeScript won't add non-type-only features that are not part of JSX.

edit: Just saw that you did post it to the JSX repo already. But given the speed that JSX advances (almost zero) I wouldn't get my hopes up.

Here's a comment regarding another issue request: #47589 (comment)

Please open an issue once the linked PR gets merged -- my sense is that is not likely to happen in the near future based on the JSX repo's general level of engagement.

[yuval-gilboa]

@MartinJohns, thanks for your quick response.
My hopes were not high, but i had to give it a try.

What about ideas for extensions to the JSX type checking system and the JSX factory namespace (#3203) that do not require any JSX syntax changes - are you open for that?.

I've some ideas for improving JSX typing/usability that can be used to perform stricter JSX validation and improve JSX intellisense. Some examples include:

1. Defining content model - i.e., which JSX elements are allowed inside which JSX elements and at which cardinality.
2. Cascading generatic type parameters of parent JSX element onto its nested child elements.
3. Defining attached element attributes (similar to the WPF attached properties concept - https://docs.microsoft.com/en-us/dotnet/desktop/wpf/properties/attached-properties-overview?view=netdesktop-6.0).

Please let me know if applicable, i will open separate requests with use cases for each.

[MartinJohns]

are you open for that?.

I'm no member of the TypeScript team, just a noisy follower.

Defining content model - i.e., which JSX elements are allowed inside which JSX elements and at which cardinality.

There's #21699 for this.

Cascading generatic type parameters of parent JSX element onto its nested child elements.

Not sure what you mean by that, but it sounds a lot related to the previous point.

Defining attached element attributes (similar to the WPF attached properties concept

This goes far beyond a type-only feature again, this would require additional runtime functionality.

[typescript-bot]

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