Support JSX shorthand properties, for compatibility with Bun

[fabiospampinato]

Suggestion

🔍 Search Terms

• jsx
• tsx
• shorthand
• properties

✅ 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

Bun implements JSX shorthand properties, presumably because they are extremely convenient to use, even though they haven't been added to the JSX spec, presumably because that's effectively dead.

📃 Motivating Example

Example code:

const onClick = console.log;
const vdom = <div {onClick} />;

console.log ( vdom );

Basically {foo} is just a shorthand for foo={foo}. The same way outside of JSX {foo} is a shorthand for {foo: foo}.

💻 Use Cases

It's a very natural extension of the syntax, and extremely convenient too, for many components that I personally write about half of the JSX is just redundant and could be deleted if I could use shorthand properties.

As massive of an improvement it is though I can't give up type-checking for it.

Basically the engine I'd like to use supports it already, the code I tend to write screams for this feature, but the JSX spec is abandonware and TS doesn't support it.

Can we please consider adding it and improve the lives of millions of developers? If that's not a strong argument enough can we consider adding this for compatibility with Bun?

I'd be more than happy to submit a PR for this.

//cc @Jarred-Sumner

[rossipedia]

It's a very natural extension of the syntax, and extremely convenient too, for many components that I personally write about half of the JSX is just redundant and could be deleted if I could use shorthand properties.

As massive of an improvement it is though I can't give up type-checking for it.

I'm going to push back against both of these statements. I don't find it natural, and I don't see it as an improvement. I find the syntax noisy and annoying to scan, because now I have to add one more syntax in my head to keep track of when it comes to passing props. It might make writing props marginally easier by saving a few keystrokes, but it will make reading those props a bit more aggravating, especially in scenarios where both the shorthand and longhand are used.

The more ways you have to achieve a single task, the more complex the language becomes, and the harder it is to learn and teach. Even for somebody like me who's been writing JS professionally for 25 years, and TS since it was introduced, I'd much prefer the language move in the direction of being easier to read and understand, even if it means I have to type a few more characters.

[a-tarasyuk]

Is this part of the JSX specification? Or is this a Bun specific syntax?

[fatcerberus]

I'm going to guess it's not in the spec, going by these remarks in the OP:

...even though they haven't beed added to the JSX spec, presumably because that's effectively dead.

Basically the engine I'd like to use supports it already, the code I tend to write screams for this feature, but the JSX spec is abandonware and TS doesn't support it.

[fatcerberus]

@rossipedia Interestingly, despite the additional syntax complexity, I do find shorthand properties to mostly improve readability--in JS. They look oddly out of place in JSX, though, for whatever reason.

[remcohaszing]

There has been some prior discussion in facebook/jsx#23.

[MartinJohns]

As a workaround you can use object spreading:

const onClick = console.log;
const vdom = <div {...{onClick}} />;

Works well with multiple attributes as well:

const onClick = console.log;
const onBlur = console.log;
const vdom = <div {...{onClick, onBlur}} />;

No idea why some people have the urge to downvote this comment when all I do is provide a viable option that already works and is supported by both JSX and TypeScript.

[mrkev]

As much as I agree with @rossipedia, the pattern @MartinJohns communicates is one I've seen quite often. In my eyes their comment is not so much a suggestion as a reminder of something that's out there being done all the time.

This has so long been a mild annoyance in JSX, and spreading is such an obvious workaround, that it's literally the first response to facebook/jsx#23.

Just like JavaScript when it stopped evolving in the "dark age" of IE6, people will find workarounds to common annoyances, and as long as <div {...{onClick, onBlur}} /> is valid JS people will do it. It's not sign of weak language design to add a feature like this. On the contrary. It's good language design to make it easier to do the right thing than to do the wrong thing, and {...{onClick, onBlur}} is both easy and "wrong".

[mrkev]

Also, there's been mumblings of JSX2 but IMO waiting for a major version to add non-breaking changes like this has disadvantages. Wondering what @sebmarkbage thinks

[sebmarkbage]

One of the major benefits of JSX is not breaking the syntax and having pretty much universal support in implementations. Although it’s not actually quite the same in all implementations.

It has allowed a lot of code to move between implementations without anyone really having to think about how amazing and unlikely that is.

I think once we pull the bandaid and accept breaking changes we can do an even better JSX. That’s what the JSX 2.0 concept is all about.

That said, if we design a JSX 1.5 without breaking changes, what would that look like as a whole? ES2015 was a lot of work because figuring out the interplay and where we wanted to go next was important.

What else would go into a potential JSX 1.5?

[Jarred-Sumner]

What else would go into a potential JSX 1.5?

Here are a couple ideas, but you would be better at answering:

• Ship template literals support
• Spec out whitespacing / line break behaviors  facebook/jsx#143. newline behavior is not consistent for string literal attribute values right now

[dsherret]

I think this should be unchecked in the viability checklist of the original post?

This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)

That should then answer the question of if this should be implemented in TypeScript at this time.

[nickserv]

I think the TypeScript team has made the right decision in not encouraging additional nonstandard syntax. JSX is acceptable, since it can still be strongly typed (and both JSX and Flow were designed to be compatible with this approach originally). But I don't think it's a good idea to implement JSX syntax that's not in Facebook's standard, as it will further fragment React and TypeScript tooling from tools implementing the syntax.

[Jarred-Sumner]

I think this should be unchecked in the viability checklist of the original post?

What makes it a runtime feature? The changes would impact build-time, but not runtime (tsc but not tslib, would not modify transpiled output in an observably different way from what <div foo={foo} /> does)

[MartinJohns]

What makes it a runtime feature?

The relevant parts are probably:

non-ECMAScript syntax with JavaScript output, new syntax sugar for JS

This is generally a no-go. Except for down leveling and legacy features added before this rule (e.g. enums) the TypeScript should output equivalent JavaScript. Though given the special situation that TSX is in it's not super clear if the rule applies here. After all the TSX is not compiled to JSX. (Unless you enable preserve, then <div {onClick} /> compiles to <div {...onClick} />.)

When the subject of JSX extensions comes up with the TypeScript team I've seen these two statements: They want to stick to the JSX spec and align with what Babel generates. Does Babel support this feature?

[fabiospampinato]

What else would go into a potential JSX 1.5?

@sebmarkbage you'd possibly know best about that, but I would like whoever has the ability to ship new features here to think "shipping what when would deliver the most value to people?"

Like maybe shipping 5 things one at a time delivers more value than shipping all 5 at once but in 5 years. Or shipping 1 feature next month maybe delivers more value than shipping 20 extremely thoughful ones but in 10 years.