Estoy aprendiendo TypeScript y algunas partes me resultan confusas. Un bit está debajo:
interface Props { name: string; } const PrintName: React.FC<Props> = (props) => { return ( <div> <p style={{ fontWeight: props.priority ? "bold" : "normal" }}> {props.name} </p> </div> ) } const PrintName2 = (props: Props) => { return ( <div> <p style={{ fontWeight: props.priority ? "bold" : "normal" }}> {props.name} </p> </div> ) }
Para los dos componentes funcionales anteriores, veo que TypeScript genera el mismo código JS. El componente PrintName2
parece más simplificado en cuanto a legibilidad. Me pregunto cuál es la diferencia entre las dos definiciones y si alguien está usando el segundo tipo de componente React.
El segundo enfoque + un tipo de retorno
const PrintName2 = ({ prop1, prop2 }: Props): JSX.Element => { /** */}
Esto te da un control completo sobre los accesorios y es más explícito (no hay magia oculta).
Enlace a GitHub PR para eliminar React.FC
Kent C Dodds tiene algunas ideas de por qué esto está aquí
La primera versión (React.FC) agregará algunos tipos para usted: provienen de React Typings
interface FunctionComponent<P = {}> { (props: PropsWithChildren<P>, context?: any): ReactElement | null; propTypes?: WeakValidationMap<P>; contextTypes?: ValidationMap<any>; defaultProps?: Partial<P>; displayName?: string; }
Este enfoque es útil por varias razones, pero una obvia es que si su componente tiene elementos secundarios, entonces no necesita agregar manualmente un objeto children
. No es genial porque hay problemas con los accesorios predeterminados y muchos componentes no tienen elementos secundarios.
Dado que está usando React y TypeScript, siempre debe usar el primer patrón, ya que garantizará que su componente tenga un tipo más estricto, ya que implica que PrintName
será del tipo React Functional Component, y admite accesorios de tipo Props
.
const PrintName: React.FC<Props>
Puede leer la definición completa de la interfaz para los componentes funcionales en el repositorio de tipos de React TypeScript.
El segundo ejemplo que ha proporcionado no proporciona ningún tipo de tipificación, excepto que es una función que toma un conjunto de parámetros de tipo Props
y que puede devolver cualquier cosa en general.
Por lo tanto, escribir
const PrintName2 = (props:Props)
es similar a
const PrintName2: JSX.Element = (props:Props)
ya que TypeScript definitivamente no puede inferir automáticamente que es un componente funcional.
Gracias por todas las respuestas. Son correctos, pero estaba buscando una versión más detallada. Investigué un poco más y encontré esto en React+TypeScript Cheatsheets en GitHub.
Componentes de funciones
Estos se pueden escribir como funciones normales que toman un argumento props y devuelven un elemento JSX.
type AppProps = { message: string }; /* could also use interface */ const App = ({ message }: AppProps) => <div>{message}</div>;
¿Qué pasa con React.FC
/ React.FunctionComponent
? También puede escribir componentes con React.FunctionComponent
(o la abreviatura React.FC
):
const App: React.FC<{ message: string }> = ({ message }) => ( <div>{message}</div> );
Algunas diferencias con la versión de "función normal":
Proporciona verificación de tipos y autocompletado para propiedades estáticas como displayName
, propTypes
y defaultProps
. Sin embargo, actualmente existen problemas conocidos al usar defaultProps
con React.FunctionComponent
. Consulte este problema para obtener más detalles: desplácese hacia abajo hasta nuestra sección defaultProps
para escribir recomendaciones allí.
Proporciona una definición implícita de niños (ver más abajo); sin embargo, hay algunos problemas con el tipo de niños implícitos (por ejemplo, DefinitelyTyped#33006), y podría considerarse un mejor estilo ser explícito sobre los componentes que consumen niños, de todos modos.
const Title: React.FunctionComponent<{ title: string }> = ({ children, title }) => <div title={title}>{children}</div>;
En el futuro, puede marcar automáticamente los accesorios como de solo lectura, aunque eso es un punto discutible si el objeto de accesorios está desestructurado en la lista de parámetros.
React.FunctionComponent
es explícito sobre el tipo de devolución, mientras que la versión normal de la función es implícita (o necesita anotaciones adicionales).
En la mayoría de los casos, hace muy poca diferencia qué sintaxis se usa, pero la sintaxis de
React.FC
es un poco más detallada sin proporcionar una ventaja clara, por lo que se le dio prioridad a la sintaxis de "función normal".
React.FC
no es la forma preferible de escribir un componente React, aquí hay un enlace .
Yo personalmente uso este tipo:
const Component1 = ({ prop1, prop2 }): JSX.Element => { /*...*/ }
Lista corta de las desventajas de React.FC
:
defaultProps
.