replace usage of deprecated global JSX in favor of React.JSX (typescript-cheatsheets#659)

* fixes usage of deprecated JSX.Element to React.JSX.Element typescript-cheatsheets#643

* gen-readme

* Migrate away from all usage of deprecated global JSX

* one more

---------

Co-authored-by: eps1lon <[email protected]>

Author: mohit-negi

README.md

@@ -190,7 +190,7 @@ type AppProps = {
 const App = ({ message }: AppProps) => <div>{message}</div>;
 
 // you can choose annotate the return type so an error is raised if you accidentally return some other type
-const App = ({ message }: AppProps): JSX.Element => <div>{message}</div>;
+const App = ({ message }: AppProps): React.JSX.Element => <div>{message}</div>;
 
 // you can also inline the type declaration; eliminates naming the prop types, but looks repetitive
 const App = ({ message }: { message: string }) => <div>{message}</div>;
@@ -921,11 +921,11 @@ let el = <Greet age={3} />;
 ```
 
 <details>
-<summary><b><code>JSX.LibraryManagedAttributes</code> nuance for library authors</b></summary>
+<summary><b><code>React.JSX.LibraryManagedAttributes</code> nuance for library authors</b></summary>
 
 The above implementations work fine for App creators, but sometimes you want to be able to export `GreetProps` so that others can consume it. The problem here is that the way `GreetProps` is defined, `age` is a required prop when it isn't because of `defaultProps`.
 
-The insight to have here is that [`GreetProps` is the _internal_ contract for your component, not the _external_, consumer facing contract](https://github.com/typescript-cheatsheets/react/issues/66#issuecomment-453878710). You could create a separate type specifically for export, or you could make use of the `JSX.LibraryManagedAttributes` utility:
+The insight to have here is that [`GreetProps` is the _internal_ contract for your component, not the _external_, consumer facing contract](https://github.com/typescript-cheatsheets/react/issues/66#issuecomment-453878710). You could create a separate type specifically for export, or you could make use of the `React.JSX.LibraryManagedAttributes` utility:
 
 ```tsx
 // internal contract, should not be exported out
@@ -938,7 +938,7 @@ class Greet extends Component<GreetProps> {
 }
 
 // external contract
-export type ApparentGreetProps = JSX.LibraryManagedAttributes<
+export type ApparentGreetProps = React.JSX.LibraryManagedAttributes<
   typeof Greet,
   GreetProps
 >;
@@ -978,13 +978,13 @@ const el = <TestComponent name="foo" />;
 
 ##### Solution
 
-Define a utility that applies `JSX.LibraryManagedAttributes`:
+Define a utility that applies `React.JSX.LibraryManagedAttributes`:
 
 ```tsx
 type ComponentProps<T> = T extends
   | React.ComponentType<infer P>
   | React.Component<infer P>
-  ? JSX.LibraryManagedAttributes<T, P>
+  ? React.JSX.LibraryManagedAttributes<T, P>
   : never;
 
 const TestComponent = (props: ComponentProps<typeof GreetComponent>) => {
@@ -1044,7 +1044,7 @@ export class MyComponent extends React.Component<IMyComponentProps> {
 }
 ```
 
-The problem with this approach is it causes complex issues with the type inference working with `JSX.LibraryManagedAttributes`. Basically it causes the compiler to think that when creating a JSX expression with that component, that all of its props are optional.
+The problem with this approach is it causes complex issues with the type inference working with `React.JSX.LibraryManagedAttributes`. Basically it causes the compiler to think that when creating a JSX expression with that component, that all of its props are optional.
 
 [See commentary by @ferdaber here](https://github.com/typescript-cheatsheets/react/issues/57) and [here](https://github.com/typescript-cheatsheets/react/issues/61).
 
@@ -1143,7 +1143,7 @@ Relevant for components that accept other React components as props.
 ```tsx
 export declare interface AppProps {
   children?: React.ReactNode; // best, accepts everything React can render
-  childrenElement: JSX.Element; // A single React element
+  childrenElement: React.JSX.Element; // A single React element
   style?: React.CSSProperties; // to pass through style props
   onChange?: React.FormEventHandler<HTMLInputElement>; // form events! the generic parameter is the type of event.target
   //  more info: https://react-typescript-cheatsheet.netlify.app/docs/advanced/patterns_by_usecase/#wrappingmirroring
@@ -1179,16 +1179,16 @@ This is because `ReactNode` includes `ReactFragment` which allowed type `{}` bef
 </details>
 
 <details>
- <summary><b>JSX.Element vs React.ReactNode?</b></summary>
+ <summary><b>React.JSX.Element vs React.ReactNode?</b></summary>
 
-Quote [@ferdaber](https://github.com/typescript-cheatsheets/react/issues/57): A more technical explanation is that a valid React node is not the same thing as what is returned by `React.createElement`. Regardless of what a component ends up rendering, `React.createElement` always returns an object, which is the `JSX.Element` interface, but `React.ReactNode` is the set of all possible return values of a component.
+Quote [@ferdaber](https://github.com/typescript-cheatsheets/react/issues/57): A more technical explanation is that a valid React node is not the same thing as what is returned by `React.createElement`. Regardless of what a component ends up rendering, `React.createElement` always returns an object, which is the `React.JSX.Element` interface, but `React.ReactNode` is the set of all possible return values of a component.
 
-- `JSX.Element` -> Return value of `React.createElement`
+- `React.JSX.Element` -> Return value of `React.createElement`
 - `React.ReactNode` -> Return value of a component
 
 </details>
 
-[More discussion: Where ReactNode does not overlap with JSX.Element](https://github.com/typescript-cheatsheets/react/issues/129)
+[More discussion: Where ReactNode does not overlap with React.JSX.Element](https://github.com/typescript-cheatsheets/react/issues/129)
 
 [Something to add? File an issue](https://github.com/typescript-cheatsheets/react/issues/new).
 

docs/advanced/patterns_by_usecase.md

@@ -50,20 +50,20 @@ You CAN use `ComponentProps` in place of `ComponentPropsWithRef`, but you may pr
 
 More info: https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/forward_and_create_ref/
 
-### Maybe `JSX.IntrinsicElements` or `[Element]HTMLAttributes`
+### Maybe `React.JSX.IntrinsicElements` or `[Element]HTMLAttributes`
 
 There are at least 2 other equivalent ways to do this, but they are more verbose:
 
 ```tsx
-// Method 1: JSX.IntrinsicElements
-type BtnType = JSX.IntrinsicElements["button"]; // cannot inline or will error
+// Method 1: React.JSX.IntrinsicElements
+type BtnType = React.JSX.IntrinsicElements["button"]; // cannot inline or will error
 export interface ButtonProps extends BtnType {} // etc
 
 // Method 2: React.[Element]HTMLAttributes
 export interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement>
 ```
 
-Looking at [the source for `ComponentProps`](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/f3134f4897c8473f590cbcdd5788da8d59796f45/types/react/index.d.ts#L821) shows that this is a clever wrapper for `JSX.IntrinsicElements`, whereas the second method relies on specialized interfaces with unfamiliar naming/capitalization.
+Looking at [the source for `ComponentProps`](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/f3134f4897c8473f590cbcdd5788da8d59796f45/types/react/index.d.ts#L821) shows that this is a clever wrapper for `React.JSX.IntrinsicElements`, whereas the second method relies on specialized interfaces with unfamiliar naming/capitalization.
 
 > Note: There are over 50 of these specialized interfaces available - look for `HTMLAttributes` in our [`@types/react` commentary](https://react-typescript-cheatsheet.netlify.app/docs/advanced/types_react_api#typesreact).
 
@@ -375,7 +375,7 @@ Parent.propTypes = {
 
 The thing you cannot do is **specify which components** the children are, e.g. If you want to express the fact that "React Router `<Routes>` can only have `<Route>` as children, nothing else is allowed" in TypeScript.
 
-This is because when you write a JSX expression (`const foo = <MyComponent foo='foo' />`), the resultant type is blackboxed into a generic JSX.Element type. (_[thanks @ferdaber](https://github.com/typescript-cheatsheets/react/issues/271)_)
+This is because when you write a JSX expression (`const foo = <MyComponent foo='foo' />`), the resultant type is blackboxed into a generic React.JSX.Element type. (_[thanks @ferdaber](https://github.com/typescript-cheatsheets/react/issues/271)_)
 
 ## Type Narrowing based on Props
 
@@ -414,8 +414,8 @@ type AnchorProps = React.AnchorHTMLAttributes<HTMLAnchorElement> & {
 
 // Input/output options
 type Overload = {
-  (props: ButtonProps): JSX.Element;
-  (props: AnchorProps): JSX.Element;
+  (props: ButtonProps): React.JSX.Element;
+  (props: AnchorProps): React.JSX.Element;
 };
 
 // Guard to check if href exists in props
@@ -438,8 +438,8 @@ Components, and JSX in general, are analogous to functions. When a component can
 A very common use case for this is to render something as either a button or an anchor, based on if it receives a `href` attribute.
 
 ```tsx
-type ButtonProps = JSX.IntrinsicElements["button"];
-type AnchorProps = JSX.IntrinsicElements["a"];
+type ButtonProps = React.JSX.IntrinsicElements["button"];
+type AnchorProps = React.JSX.IntrinsicElements["a"];
 
 // optionally use a custom type guard
 function isPropsForAnchorElement(
@@ -460,7 +460,9 @@ function Clickable(props: ButtonProps | AnchorProps) {
 They don't even need to be completely different props, as long as they have at least one difference in properties:
 
 ```tsx
-type LinkProps = Omit<JSX.IntrinsicElements["a"], "href"> & { to?: string };
+type LinkProps = Omit<React.JSX.IntrinsicElements["a"], "href"> & {
+  to?: string;
+};
 
 function RouterLink(props: LinkProps | AnchorProps) {
   if ("href" in props) {
@@ -808,8 +810,8 @@ type NoTruncateProps = CommonProps & { truncate?: false };
 type TruncateProps = CommonProps & { truncate: true; expanded?: boolean };
 
 // Function overloads to accept both prop types NoTruncateProps & TruncateProps
-function Text(props: NoTruncateProps): JSX.Element;
-function Text(props: TruncateProps): JSX.Element;
+function Text(props: NoTruncateProps): React.JSX.Element;
+function Text(props: TruncateProps): React.JSX.Element;
 function Text(props: CommonProps & { truncate?: boolean; expanded?: boolean }) {
   const { children, truncate, expanded, ...otherProps } = props;
   const classNames = truncate ? ".truncate" : "";

docs/advanced/types-react-ap.md

@@ -37,7 +37,7 @@ Not Commonly Used but Good to know
 - `ComponentProps` - props of a component - most useful for [Wrapping/Mirroring a HTML Element](https://react-typescript-cheatsheet.netlify.app/docs/advanced/patterns_by_usecase#wrappingmirroring-a-html-element)
 - `ComponentPropsWithRef` - props of a component where if it is a class-based component it will replace the `ref` prop with its own instance type
 - `ComponentPropsWithoutRef` - props of a component without its `ref` prop
-- `HTMLProps` and `HTMLAttributes` - these are the most generic versions, for global attributes (see a list of [attributes marked as "global attribute" on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes)). In general, prefer `React.ComponentProps`, `JSX.IntrinsicElements`, or [specialized HTMLAttributes interfaces](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a2aa0406e7bf269eef01292fcb2b24dee89a7d2b/types/react/index.d.ts#L1914-L2625):
+- `HTMLProps` and `HTMLAttributes` - these are the most generic versions, for global attributes (see a list of [attributes marked as "global attribute" on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes)). In general, prefer `React.ComponentProps`, `React.JSX.IntrinsicElements`, or [specialized HTMLAttributes interfaces](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a2aa0406e7bf269eef01292fcb2b24dee89a7d2b/types/react/index.d.ts#L1914-L2625):
 
 <details>
   <summary>
@@ -102,7 +102,7 @@ Note that there are about 50 of these, which means there are some HTML elements
 
 - all methods: `createElement`, `cloneElement`, ... are all public and reflect the React runtime API
 
-[@Ferdaber's note](https://github.com/typescript-cheatsheets/react/pull/69): I discourage the use of most `...Element` types because of how black-boxy `JSX.Element` is. You should almost always assume that anything produced by `React.createElement` is the base type `React.ReactElement`.
+[@Ferdaber's note](https://github.com/typescript-cheatsheets/react/pull/69): I discourage the use of most `...Element` types because of how black-boxy `React.JSX.Element` is. You should almost always assume that anything produced by `React.createElement` is the base type `React.ReactElement`.
 
 **Namespace: JSX**
 

docs/basic/getting-started/basic-type-examples.md

@@ -88,7 +88,7 @@ Relevant for components that accept other React components as props.
 ```tsx
 export declare interface AppProps {
   children?: React.ReactNode; // best, accepts everything React can render
-  childrenElement: JSX.Element; // A single React element
+  childrenElement: React.JSX.Element; // A single React element
   style?: React.CSSProperties; // to pass through style props
   onChange?: React.FormEventHandler<HTMLInputElement>; // form events! the generic parameter is the type of event.target
   //  more info: https://react-typescript-cheatsheet.netlify.app/docs/advanced/patterns_by_usecase/#wrappingmirroring
@@ -124,16 +124,16 @@ This is because `ReactNode` includes `ReactFragment` which allowed type `{}` bef
 </details>
 
 <details>
- <summary><b>JSX.Element vs React.ReactNode?</b></summary>
+ <summary><b>React.JSX.Element vs React.ReactNode?</b></summary>
 
-Quote [@ferdaber](https://github.com/typescript-cheatsheets/react/issues/57): A more technical explanation is that a valid React node is not the same thing as what is returned by `React.createElement`. Regardless of what a component ends up rendering, `React.createElement` always returns an object, which is the `JSX.Element` interface, but `React.ReactNode` is the set of all possible return values of a component.
+Quote [@ferdaber](https://github.com/typescript-cheatsheets/react/issues/57): A more technical explanation is that a valid React node is not the same thing as what is returned by `React.createElement`. Regardless of what a component ends up rendering, `React.createElement` always returns an object, which is the `React.JSX.Element` interface, but `React.ReactNode` is the set of all possible return values of a component.
 
-- `JSX.Element` -> Return value of `React.createElement`
+- `React.JSX.Element` -> Return value of `React.createElement`
 - `React.ReactNode` -> Return value of a component
 
 </details>
 
-[More discussion: Where ReactNode does not overlap with JSX.Element](https://github.com/typescript-cheatsheets/react/issues/129)
+[More discussion: Where ReactNode does not overlap with React.JSX.Element](https://github.com/typescript-cheatsheets/react/issues/129)
 
 [Something to add? File an issue](https://github.com/typescript-cheatsheets/react/issues/new).
 

docs/basic/getting-started/default-props.md

@@ -80,11 +80,11 @@ let el = <Greet age={3} />;
 ```
 
 <details>
-<summary><b><code>JSX.LibraryManagedAttributes</code> nuance for library authors</b></summary>
+<summary><b><code>React.JSX.LibraryManagedAttributes</code> nuance for library authors</b></summary>
 
 The above implementations work fine for App creators, but sometimes you want to be able to export `GreetProps` so that others can consume it. The problem here is that the way `GreetProps` is defined, `age` is a required prop when it isn't because of `defaultProps`.
 
-The insight to have here is that [`GreetProps` is the _internal_ contract for your component, not the _external_, consumer facing contract](https://github.com/typescript-cheatsheets/react/issues/66#issuecomment-453878710). You could create a separate type specifically for export, or you could make use of the `JSX.LibraryManagedAttributes` utility:
+The insight to have here is that [`GreetProps` is the _internal_ contract for your component, not the _external_, consumer facing contract](https://github.com/typescript-cheatsheets/react/issues/66#issuecomment-453878710). You could create a separate type specifically for export, or you could make use of the `React.JSX.LibraryManagedAttributes` utility:
 
 ```tsx
 // internal contract, should not be exported out
@@ -97,7 +97,7 @@ class Greet extends Component<GreetProps> {
 }
 
 // external contract
-export type ApparentGreetProps = JSX.LibraryManagedAttributes<
+export type ApparentGreetProps = React.JSX.LibraryManagedAttributes<
   typeof Greet,
   GreetProps
 >;
@@ -137,13 +137,13 @@ const el = <TestComponent name="foo" />;
 
 ### Solution
 
-Define a utility that applies `JSX.LibraryManagedAttributes`:
+Define a utility that applies `React.JSX.LibraryManagedAttributes`:
 
 ```tsx
 type ComponentProps<T> = T extends
   | React.ComponentType<infer P>
   | React.Component<infer P>
-  ? JSX.LibraryManagedAttributes<T, P>
+  ? React.JSX.LibraryManagedAttributes<T, P>
   : never;
 
 const TestComponent = (props: ComponentProps<typeof GreetComponent>) => {
@@ -203,7 +203,7 @@ export class MyComponent extends React.Component<IMyComponentProps> {
 }
 ```
 
-The problem with this approach is it causes complex issues with the type inference working with `JSX.LibraryManagedAttributes`. Basically it causes the compiler to think that when creating a JSX expression with that component, that all of its props are optional.
+The problem with this approach is it causes complex issues with the type inference working with `React.JSX.LibraryManagedAttributes`. Basically it causes the compiler to think that when creating a JSX expression with that component, that all of its props are optional.
 
 [See commentary by @ferdaber here](https://github.com/typescript-cheatsheets/react/issues/57) and [here](https://github.com/typescript-cheatsheets/react/issues/61).
 

docs/basic/getting-started/function-components.md

@@ -15,7 +15,7 @@ type AppProps = {
 const App = ({ message }: AppProps) => <div>{message}</div>;
 
 // you can choose annotate the return type so an error is raised if you accidentally return some other type
-const App = ({ message }: AppProps): JSX.Element => <div>{message}</div>;
+const App = ({ message }: AppProps): React.JSX.Element => <div>{message}</div>;
 
 // you can also inline the type declaration; eliminates naming the prop types, but looks repetitive
 const App = ({ message }: { message: string }) => <div>{message}</div>;

docs/hoc/excluding-props.md

@@ -69,7 +69,7 @@ function withOwner(owner: string) {
   return function <T extends { owner: string }>(
     Component: React.ComponentType<T>
   ) {
-    return function (props: Omit<T, "owner">): JSX.Element {
+    return function (props: Omit<T, "owner">): React.JSX.Element {
       const newProps = { ...props, owner } as T;
       return <Component {...newProps} />;
     };
@@ -94,7 +94,7 @@ function withInjectedProps<U extends Record<string, unknown>>(
   injectedProps: U
 ) {
   return function <T extends U>(Component: React.ComponentType<T>) {
-    return function (props: Omit<T, keyof U>): JSX.Element {
+    return function (props: Omit<T, keyof U>): React.JSX.Element {
       //A type coercion is neccessary because TypeScript doesn't know that the Omit<T, keyof U> + {...injectedProps} = T
       const newProps = { ...props, ...injectedProps } as T;
       return <Component {...newProps} />;

docs/hoc/index.md

@@ -29,13 +29,13 @@ const withSampleHoC = <P extends {}>(
 
   componentName = component.displayName ?? component.name
 ): {
-  (props: P): JSX.Element;
+  (props: P): React.JSX.Element;
   displayName: string;
 } => {
 
   function WithSampleHoc(props: P) {
     //Do something special to justify the HoC.
-    return component(props) as JSX.Element;
+    return component(props) as React.JSX.Element;
   }
 
   WithSampleHoc.displayName = `withSampleHoC(${componentName})`;
@@ -50,7 +50,7 @@ const withSampleHoC = <P extends {}>(
 
 This code meets these criteria:
 
-1. Allows a component to return valid elements (`strings | array | boolean | null | number`) and not just `JSX.Element | null`.
+1. Allows a component to return valid elements (`strings | array | boolean | null | number`) and not just `React.JSX.Element | null`.
 2. Wraps it in a memo unless you opt out.
 3. Removes the nested component, so React Dev tools will just show one component.
 4. Indicates with `displayName` in React Dev Tool with an annotation that this is a component wrapped in two HoCs