From 2a423c0b427cd0122873cbcde9125ede18287002 Mon Sep 17 00:00:00 2001
From: Retsam <chess19@gmail.com>
Date: Fri, 12 Apr 2019 20:44:22 -0400
Subject: [PATCH 1/4] BASIC - Rework Function Components section to prefer
 normal function syntax

---
 README.md | 31 ++++++++++++++-----------------
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/README.md b/README.md
index d63f0ec5..b6ebbfc1 100644
--- a/README.md
+++ b/README.md
@@ -145,30 +145,29 @@ Please PR or [File an issue](https://github.com/sw-yx/react-typescript-cheatshee
 
 ## Function Components
 
-You can specify the type of props as you use them and rely on type inference:
+These can be written as normal functions that take a props argument and return a JSX element.
 
 ```tsx
 const App = ({ message }: { message: string }) => <div>{message}</div>;
 ```
 
-Or you can use the provided generic type for function components:
+<details>
+
+<summary><b>What about `React.FC`/`React.FunctionComponent`?</b></summary>
+
+You can also write components with `React.FunctionComponent` (or the shorthand `React.FC`):
 
 ```tsx
 const App: React.FC<{ message: string }> = ({ message }) => (
   <div>{message}</div>
-); // React.FunctionComponent also works
+);
 ```
 
-<details>
-
-<summary><b>What's the difference?</b></summary>
+Some differences from the "normal function" version:
 
-The former pattern is shorter, so why would people use `React.FunctionComponent` at all?
+- It provides typechecking and autocomplete for static properties like `displayName`, `propTypes`, and `defaultProps` - HOWEVER, there are currently known issues using `defaultProps` with `React.FunctionComponent`. See [this issue for details](https://github.com/sw-yx/react-typescript-cheatsheet/issues/87) - scroll down to our `defaultProps` section for typing recommendations there.
 
-- If you need to use `children` property inside the function body, in the former case it has to be added explicitly. `FunctionComponent<T>` already includes the correctly typed `children` property which then doesn't have to become part of your type.
-- Typing your function explicitly will also give you typechecking and autocomplete on its static properties, like `displayName`, `propTypes`, and `defaultProps`.
-- _In future_, it will also set `readonly` on your props just like `React.Component<T>` does.
-- HOWEVER, there are currently known issues using `defaultProps` with `React.FunctionComponent`. See [this issue for details](https://github.com/sw-yx/react-typescript-cheatsheet/issues/87) - scroll down to our `defaultProps` section for typing recommendations there.
+- It provides an implicit definition of `children` (see below) - however there are some issues with the implicit `children` type (e.g. [DefinitelyTyped#33006](https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33006)), and it might considered better style to be explicit about components that consume `children`, anyway.
 
 ```tsx
 const Title: React.FunctionComponent<{ title: string }> = ({
@@ -177,13 +176,11 @@ const Title: React.FunctionComponent<{ title: string }> = ({
 }) => <div title={title}>{children}</div>;
 ```
 
-If you want to use the `function` keyword instead of an arrow function, you can use this syntax (using a function expression, instead of declaration):
+- _In the future_, it may automatically mark props as `readonly`, though that's a moot point if the props object is destructured in the constructor.
 
-```tsx
-const App: React.FunctionComponent<{ message: string }> = function App({ message }) {
-  return <div>{message}</div>;
-}
-```
+- `React.FunctionComponent` is explicit about the return type, while the normal function version is implict (or else needs additional annotation).
+
+In most cases it makes very little difference which syntax is used, but the `React.FC` syntax is slightly more verbose without providing clear advantage, so precedence was given to the "normal function" syntax.
 
 </details>
 

From 0490f02d7106efdb8d2e6b3bc36b2686b58caee6 Mon Sep 17 00:00:00 2001
From: Retsam <chess19@gmail.com>
Date: Fri, 12 Apr 2019 20:46:25 -0400
Subject: [PATCH 2/4] Split props into its own type

---
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index b6ebbfc1..f2620c13 100644
--- a/README.md
+++ b/README.md
@@ -148,7 +148,8 @@ Please PR or [File an issue](https://github.com/sw-yx/react-typescript-cheatshee
 These can be written as normal functions that take a props argument and return a JSX element.
 
 ```tsx
-const App = ({ message }: { message: string }) => <div>{message}</div>;
+type AppProps { message: string }; /* could also use interface */
+const App = ({ message }: AppProps) => <div>{message}</div>;
 ```
 
 <details>

From 2427ea9f3d13ab853fc3f06bbd705f92a456c462 Mon Sep 17 00:00:00 2001
From: Ferdy Budhidharma <ferd312@gmail.com>
Date: Mon, 15 Apr 2019 11:37:29 -0400
Subject: [PATCH 3/4] Fix typo 'implicit'

Co-Authored-By: Retsam <Retsam@users.noreply.github.com>
---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index f2620c13..8bb4053f 100644
--- a/README.md
+++ b/README.md
@@ -179,7 +179,7 @@ const Title: React.FunctionComponent<{ title: string }> = ({
 
 - _In the future_, it may automatically mark props as `readonly`, though that's a moot point if the props object is destructured in the constructor.
 
-- `React.FunctionComponent` is explicit about the return type, while the normal function version is implict (or else needs additional annotation).
+- `React.FunctionComponent` is explicit about the return type, while the normal function version is implicit (or else needs additional annotation).
 
 In most cases it makes very little difference which syntax is used, but the `React.FC` syntax is slightly more verbose without providing clear advantage, so precedence was given to the "normal function" syntax.
 

From cdb447b2cce455604aa77643b8b635faf20bc8a8 Mon Sep 17 00:00:00 2001
From: Ferdy Budhidharma <ferd312@gmail.com>
Date: Mon, 15 Apr 2019 11:40:17 -0400
Subject: [PATCH 4/4] Formatting fixes from PR

Co-Authored-By: Retsam <Retsam@users.noreply.github.com>
---
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 8bb4053f..e342669d 100644
--- a/README.md
+++ b/README.md
@@ -145,7 +145,7 @@ Please PR or [File an issue](https://github.com/sw-yx/react-typescript-cheatshee
 
 ## Function Components
 
-These can be written as normal functions that take a props argument and return a JSX element.
+These can be written as normal functions that take a `props` argument and return a JSX element.
 
 ```tsx
 type AppProps { message: string }; /* could also use interface */
@@ -166,7 +166,7 @@ const App: React.FC<{ message: string }> = ({ message }) => (
 
 Some differences from the "normal function" version:
 
-- It provides typechecking and autocomplete for static properties like `displayName`, `propTypes`, and `defaultProps` - HOWEVER, there are currently known issues using `defaultProps` with `React.FunctionComponent`. See [this issue for details](https://github.com/sw-yx/react-typescript-cheatsheet/issues/87) - scroll down to our `defaultProps` section for typing recommendations there.
+- It provides typechecking and autocomplete for static properties like `displayName`, `propTypes`, and `defaultProps` - **However**, there are currently known issues using `defaultProps` with `React.FunctionComponent`. See [this issue for details](https://github.com/sw-yx/react-typescript-cheatsheet/issues/87) - scroll down to our `defaultProps` section for typing recommendations there.
 
 - It provides an implicit definition of `children` (see below) - however there are some issues with the implicit `children` type (e.g. [DefinitelyTyped#33006](https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33006)), and it might considered better style to be explicit about components that consume `children`, anyway.