Thanks all for the answers. They are correct but I was looking for a more detailed version. I did some more research and found this on React+TypeScript Cheatsheets on GitHub.
Function Components
These can be written as normal functions that take a props argument and return a JSX element.
type AppProps = { message: string }; /* could also use interface */
const App = ({ message }: AppProps) => <div>{message}</div>;
What about React.FC
/React.FunctionComponent
?
You can also write components with React.FunctionComponent
(or the shorthand React.FC
):
const App: React.FC<{ message: string }> = ({ message }) => (
<div>{message}</div>
);
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 - 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), and it might be considered a better style to be explicit about components that consume children, anyway.
const Title: React.FunctionComponent<{ title: string }> = ({
children,
title
}) => <div title={title}>{children}</div>;
In the future, it may automatically mark props as readonly, though that's a moot point if the props object is destructured in the parameter list.
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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…