Add type definitions for the React jsx runtime

[remcohaszing]

Although one typically shouldn’t use this directly, there are some legitimate use cases for it.

React 15 provides Fragment only through the automatic runtime, not via the index file. The type for Fragment has been backported into the jsx runtime from a newer version.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change.
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm test <package to test>.

Select one of these and delete the others:

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/facebook/react/blob/main/packages/react/jsx-runtime.js https://github.com/facebook/react/blob/main/packages/react/jsx-dev-runtime.js
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.

[typescript-bot]

@remcohaszing Thank you for submitting this PR!

This is a live comment which I will keep updated.

1 package in this PR

• react — on npm, on unpkg

Code Reviews

Because this is a widely-used package, a DT maintainer will need to review it before it can be merged.

You can test the changes of this PR in the Playground.

Status

• ✅ No merge conflicts
• ✅ Continuous integration tests have passed
• 🕐 Only a DT maintainer can approve changes without tests

Once every item on this list is checked, I'll ask you for permission to merge and publish the changes.

Inactive

This PR has been inactive for 8 days.

---

Diagnostic Information: What the bot saw about this PR

{
  "type": "info",
  "now": "-",
  "pr_number": 64661,
  "author": "remcohaszing",
  "headCommitOid": "8df849702b776f5a4ff9ff0b1ca1f9913fcaa092",
  "mergeBaseOid": "a885197773d729c49c09e9424a41da0c8e69f544",
  "lastPushDate": "2023-03-10T17:04:31.000Z",
  "lastActivityDate": "2023-04-06T08:49:35.000Z",
  "hasMergeConflict": false,
  "isFirstContribution": false,
  "tooManyFiles": false,
  "hugeChange": false,
  "popularityLevel": "Critical",
  "pkgInfo": [
    {
      "name": "react",
      "kind": "edit",
      "files": [
        {
          "path": "types/react/jsx-dev-runtime.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/react/jsx-runtime.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/react/v15/jsx-dev-runtime.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/react/v15/jsx-runtime.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/react/v16/jsx-dev-runtime.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/react/v16/jsx-runtime.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/react/v17/jsx-dev-runtime.d.ts",
          "kind": "definition"
        },
        {
          "path": "types/react/v17/jsx-runtime.d.ts",
          "kind": "definition"
        }
      ],
      "owners": [
        "johnnyreilly",
        "bbenezech",
        "pzavolinsky",
        "ericanderson",
        "DovydasNavickas",
        "theruther4d",
        "guilhermehubner",
        "ferdaber",
        "jrakotoharisoa",
        "pascaloliv",
        "hotell",
        "franklixuefei",
        "Jessidhia",
        "saranshkataria",
        "lukyth",
        "eps1lon",
        "zieka",
        "dancerphil",
        "dimitropoulos",
        "disjukr",
        "vhfmag",
        "hellatan",
        "priyanshurav",
        "Semigradsky"
      ],
      "addedOwners": [],
      "deletedOwners": [],
      "popularityLevel": "Critical"
    }
  ],
  "reviews": [
    {
      "type": "changereq",
      "reviewer": "eps1lon",
      "date": "2023-03-27T18:42:12.000Z"
    },
    {
      "type": "approved",
      "reviewer": "nickrttn",
      "date": "2023-03-23T13:37:57.000Z",
      "isMaintainer": false
    }
  ],
  "mainBotCommentID": 1463932644,
  "ciResult": "pass"
}

[typescript-bot]

🔔 @johnnyreilly @bbenezech @pzavolinsky @ericanderson @DovydasNavickas @theruther4d @guilhermehubner @ferdaber @jrakotoharisoa @pascaloliv @Hotell @franklixuefei @Jessidhia @saranshkataria @lukyth @eps1lon @zieka @dancerphil @dimitropoulos @disjukr @vhfmag @hellatan @priyanshurav @Semigradsky — please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

[typescript-bot]

@remcohaszing The CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

Note: builds which are failing do not end up on the list of PRs for the DT maintainers to review.

[DangerBotOSS]

Inspecting the JavaScript source for this package found some properties that are not in the .d.ts files.
The check for missing properties isn't always right, so take this list as advice, not a requirement.

react (unpkg)

was missing the following properties:

1. unstable_act

Generated by 🚫 dangerJS against 8df8497

[typescript-bot]

Re-ping @johnnyreilly, @bbenezech, @pzavolinsky, @ericanderson, @DovydasNavickas, @theruther4d, @guilhermehubner, @ferdaber, @jrakotoharisoa, @pascaloliv, @Hotell, @franklixuefei, @Jessidhia, @saranshkataria, @lukyth, @eps1lon, @zieka, @dancerphil, @dimitropoulos, @disjukr, @vhfmag, @hellatan, @priyanshurav, @Semigradsky:

This PR has been out for over a week, yet I haven't seen any reviews.

Could someone please give it some attention? Thanks!

[nickrttn]

ElementType takes a generic P for the type of props. Would it make sense to pass that here as well with the same signature for the generic (P = any)?

[remcohaszing]

Technically I could go even further and implement the same overrides as for createElement(). didn’t want to overcomplicate these types though, as legitimate use cases are rare.

[weswigham]

I actually do want to use these functions' types to typecheck JSX in TS itself, so there would be value in making them more accurate, this way the types would be better when such checking is enabled. Ideally, at least as good as JSX tags are checked today.

[remcohaszing]

This is unrelated to the type checking of JSX syntax. JSX expressions for the automatic runtime are checked using the global JSX namespace. See the TypeScript handbook on JSX. These functions do get used at runtime, so I understand the confusion.

[eps1lon]

@weswigham Can you share a bit more information how that will look? Specifically with regard to microsoft/TypeScript#14729 (comment)?

In the past, performance concerns were raised. React's JSX factories were never really tested for use in JSX type-checking. To avoid a chicken-egg problem (JSX factories being poorly typed vs TS not consulting JSX factories because poor types), I'd be nice if you could share TS canaries once ready so that I can check how to best type the JSX factories out.

[eps1lon]

Do you have a concrete example where these are used today and need types? Ideally as tests added to this repo.

[eps1lon]

Why do we need types for them now? It feels a bit scary to publish them without any actual usage or tests. I'd like to avoid people using them since that's not their intended purpose.

[remcohaszing]

1. In a project I work on, we inject our own automatic runtime. This runtime implements the development runtime and uses the positional information it provides, then forwards the input into React’s production runtime. I understand this is a niche use case, but it is a use case nonetheless.
2. Recently both SolidJS and Vue added support for the JSX automatic runtime. Both implemented it wrong initially. Since React is the de-facto standard JSX implementation, I think this could help other frameworks use it as a point of reference for implementing their own.
3. This is part of the public interface of React. I think they want you to write JSX and compile. However, when inspecting compiled code, these functions show up.

Of course I’ll gladly add tests, but I prefer to do so after convincing you this should be included at all. :)

[eps1lon]

However, when inspecting compiled code, these functions show up.

I don't understand how that's relevant to the types. It sounds like you're debugging the transformer plugin and want to use the types to verify?

The larger point is that type-checking JSX is different than normal type-checking in TS. You can't just transform JSX, type-check and expect the same result. I'd like to avoid giving that impression. Otherwise we end up with types like that for createElement which are way more complicated than they need to be.

If TypeScript uses the runtime types for type-checking, we need to rethink their types anyway. I'd rather test this either with their intended design that's going to ship or, if they don't want to collaborate on that, work on it once shipped.

But building them out before just adds more technical debt.

Both implemented it wrong initially.

What mistakes did they make?

[remcohaszing]

The use case I need it for is the first in the list. I need to wrap React’s automatic runtime, which requires these type definitions.

However, when inspecting compiled code, these functions show up.

I don't understand how that's relevant to the types.

For example, create a new directory, and install a React library:

mkdir project
cd project
npm install @mui/material

Now open ./node_modules/@mui/material/Accordion/Accordion.js. It has these jsx and jsxs variables. TypeScript doesn’t know them, so it shows them as any. I think having these types helps users understand a tiny bit better what these functions are, and what code they’re actually running.

It sounds like you're debugging the transformer plugin and want to use the types to verify?

Not currently, but I have contributed to the JSX transformer in MDX. I see how that could be a potential use case.

The larger point is that type-checking JSX is different than normal type-checking in TS. You can't just transform JSX, type-check and expect the same result. I'd like to avoid giving that impression. Otherwise we end up with types like that for createElement which are way more complicated than they need to be.

I am fully aware how type checking JSX works for both the classic and automatic runtime. I share your sentiment to avoid overcomplication, which is why I kept the types minimal.

If TypeScript uses the runtime types for type-checking, we need to rethink their types anyway. I'd rather test this either with their intended design that's going to ship or, if they don't want to collaborate on that, work on it once shipped.

I’m not aware any work is being done on that.

Both implemented it wrong initially.

What mistakes did they make?

Both basically exported the classic runtime pragma as jsx, jsxs, and jsxDEV. It’s fixed now. I feel this is out of scope for the discussion. My point is these types might help framework authors by providing a reference of how to implement the automatic runtime.

[eps1lon]

I’m not aware any work is being done on that.

It's scheduled for 5.1 (microsoft/TypeScript#53031) which is why I'm hesitant to work on this now in parallel until we have clarification from the TypeScript team. Which is usually after things have shipped which makes me even more hesitant to continue on this at this time.

[remcohaszing]

I wasn't aware of that. Then it makes perfect sense to delay this.

[remcohaszing]

I’ll close this PR in favor of whatever implementation will be added once TypeScript 5.1 is released. :)

[typescript-bot]

@remcohaszing One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits. Thank you!