Skip to content
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

When using react-jsx, don't treat "key" property as special unless it's specified as IntrinsicAttribute #58575

Closed
6 tasks done
dawidgarus opened this issue May 19, 2024 · 6 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@dawidgarus
Copy link

πŸ” Search Terms

jsx, react-jsx, key property

βœ… Viability Checklist

⭐ Suggestion

When "jsx" is set to "react-jsx" the key property is missing from parameters passed to jsx function and instead is passed as separate argument.
For example:

<Test param="1" key="2" />

Is compiled into:

jsx_(Test, { param: '1' }, '2')

My suggestion is to ignore this behavior unless "key" property is defined as IntrinsicAttribute.
Then, if key is not an intrinsic attribute, the example should compile into:

jsx_(Test, { param: '1', key: '2' })

πŸ“ƒ Motivating Example

It makes TSX more generic for use by any library, and less React specific

πŸ’» Use Cases

This special treatment of "key" property is at odds with libraries other that react that DON'T treat key differently, making if effectively an restricted parameter.

As a workaround, you can merger parameters with key inside jsx function:

function jsx(name, params, key) {
  const newParams = {...params, key};
  // ...
}

But this may lead to weird special cases, like this:

<Test key="key" {...params} />

key attribute will override existing key property from params.

Please make tsx friendly for libraries other than react.

@fatcerberus
Copy link

It makes TSX more generic for use by any library, and less React specific

But... you specifically asked for react-jsx...

@dawidgarus
Copy link
Author

dawidgarus commented May 19, 2024

It makes TSX more generic for use by any library, and less React specific

But... you specifically asked for react-jsx...

If react-jsx is to be used only with react, then why don't we have "jsxImportSource" hardcoded to "react"? Or in other words, the ONLY way to use tsx for anything other than react is to set "jsx" to "preserve", because only "preserve" doesn't have the word react in it. Is that the official stance of TypeScript?

@Josh-Cena
Copy link
Contributor

react-jsx means "compile JSX syntax using React semantics" so yes if your JSX flavor is non-React-compatible you would use preserve.

@nmain
Copy link

nmain commented May 20, 2024

tsx for anything other than react

View frameworks exist that are not React, not React-compatible, but still are compatible only in the jsx function.

There's also the react preset for Typescript, which transforms to a function call (usually named React.createElement or h) with slightly different children semantics, and has no special semantics for key.

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jun 6, 2024
@RyanCavanaugh
Copy link
Member

We don't do type-directed emit, which is what this is asking for.

jsx: react doesn't have the key special-casing; it's more accurately thought of as the JSX semantics of ~2016 that predate _jsx

jsx: react-jsx really does include React-specific semantics

jsx: preserve exists if neither of those work for your scenario

@typescript-bot
Copy link
Collaborator

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

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

6 participants