From 83d1b53c89b45fe779c24abf3b5c93c01d4735cc Mon Sep 17 00:00:00 2001
From: MOHITNEGI999 <mohitneg377@gmail.com>
Date: Mon, 2 Oct 2023 12:10:37 +0530
Subject: [PATCH] fixes usage of deprecated JSX.Element to React.JSX.Element
 #643

---
 docs/basic/getting-started/basic-type-examples.md | 10 +++++-----
 docs/basic/getting-started/function-components.md |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/basic/getting-started/basic-type-examples.md b/docs/basic/getting-started/basic-type-examples.md
index 043a5a22..517ec367 100644
--- a/docs/basic/getting-started/basic-type-examples.md
+++ b/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).
 
diff --git a/docs/basic/getting-started/function-components.md b/docs/basic/getting-started/function-components.md
index 5d637839..fdb66243 100644
--- a/docs/basic/getting-started/function-components.md
+++ b/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>;