Skip to content

BASIC - Rework Function Components section to prefer normal function … #104

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

Merged
merged 4 commits into from
Apr 15, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 16 additions & 18 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -145,30 +145,30 @@ 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>;
type AppProps { message: string }; /* could also use interface */
const App = ({ message }: AppProps) => <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 }> = ({
Expand All @@ -177,13 +177,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 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.

</details>

Expand Down