7 Patrones de TypeScript que Deberías Estar Utilizando

¿Sabías que a pesar de que alrededor del 80% de los desarrolladores de React están utilizando TypeScript, la mayoría de los cursos, libros y materiales de apoyo para aprender React están casi exclusivamente en JavaScript? Esto ha dejado a muchos desarrolladores luchando por navegar el complejo papel de TypeScript en el desarrollo de React.

Hoy, estoy aquí para cambiar todo eso. Quiero compartir contigo 7 patrones esenciales de TypeScript que puedes comenzar a usar de inmediato para hacer tu desarrollo de React más seguro, eficiente y agradable que nunca. Mi nombre es Morten y me gustan mucho los perros. Estoy aquí como entusiasta tanto de React como de TypeScript. Soy el autor de 2 libros sobre React. Primero, React Rápido, una introducción a los fundamentos de React. Está prácticamente en imprenta y saldrá en formato impreso este mes. En segundo lugar, React Listo para el Trabajo. Se basa en el primer libro. Cubre el ecosistema de React y patrones de React más complejos. Está en proceso, aproximadamente 80% completado, y saldrá en otoño. Puedes obtener los libros desde los dos enlaces anteriores o simplemente buscando los títulos en Google. Además de eso, también imparto talleres y estoy trabajando en una nueva plataforma de cursos que creo que será bastante innovadora. Puedes leer más al respecto en codingheaven.deb. Por último, sígueme en LinkedIn y por favor suscríbete a mi boletín en mortenbaklund.com para obtener muchos más consejos y trucos.

De acuerdo, volvamos al tema. El título aquí es un poco exagerado. Estos patrones tienden a mezclarse un poco entre sí, pero el plan general es el siguiente. Presentaremos lo que queremos lograr al ver la aplicación final. Luego, analizaremos la API desde la perspectiva del componente padre y luego veremos cómo podemos implementarlo dentro de un componente. Probablemente veremos algunas variaciones diferentes y veremos cuál es la mejor.

Los ejemplos no siempre son un código excelente porque algunos de estos ejemplos se han reducido un poco en complejidad para que sean simples e instructivos. Los patrones siguen siendo totalmente válidos, pero solo aparecen en código más complejo. Así que a veces he sacrificado un poco la correcta codificación de React para ilustrar algunos puntos.

Estos son los siete patrones que cubriremos. Children, spreading props, either-or, componentes genéricos y contexto. Es posible que ahora estés pensando, espera, ¿eran siete o solo cinco? Así que ampliemos un poco la lista porque podemos hacer esto de varias formas diferentes. Por ejemplo, either-or, podemos hacerlo con uniones o uniones discriminadas. Esos son patrones ligeramente diferentes que definitivamente son válidos. Y para el contexto, hay dos situaciones diferentes que definitivamente tienen una complejidad diferente. Tenemos contexto simple y contexto seleccionable. Esos son muy diferentes y veremos cómo podemos implementar ambos.

En esta charla, trabajaré en una aplicación llamada Waxville. Es un salón de aseo ficticio para perros que he creado especialmente para esta charla. Puedes ver el repositorio aquí en GitHub y puedes ver el sitio web en vivo en waxville.org. Puedes ir a verlo ahora mismo. Esta es solo una demostración rápida en la que puedes iniciar sesión. No importa lo que escribas. Cuando presionas el botón, inicias sesión y luego hay un horario con las citas diarias, y hay una interfaz CRUD para empleados, clientes y servicios. Ten en cuenta que este es un sitio web muy simple. Solo almacena los datos en memoria. Así que una vez que recargas el sitio web, todo lo que has hecho desaparece. Esto es para asegurarnos de que nadie lo manipule, pero también es suficiente para ilustrar todos los puntos que vamos a tratar. No se trata de APIs de datos. Solo se trata de escribir componentes.

Entonces, el primer patrón que vamos a discutir es children. Children es una propiedad especial que probablemente todos conozcan y debe ser tipada correctamente para permitir que el nodo contenga todos los diferentes tipos posibles de contenido hijo. Un ejemplo sería nuestro proveedor de autenticación que tenemos en la raíz de nuestra aplicación. Podemos tiparlo usando una interfaz personalizada y simplemente tipar la propiedad children como react-node del paquete react. Este tipo incluye todas las posibilidades correctas, incluyendo cadenas, números, booleanos, elementos, listas, etc.

Sin embargo, creo que un enfoque mejor y más transparente es usar la interfaz props with children del paquete react en su lugar. No necesitamos tener nuestra propia interfaz en absoluto cuando no tenemos props adicionales. Simplemente usamos esta interfaz tal cual. Esto hace que sea más claro que hemos tipado correctamente esta propiedad children. Si nuestro componente toma otras propiedades, también podemos manejar eso fácilmente. Aquí tenemos el menú con elementos de menú. Un elemento de menú toma un atributo child, pero también toma una propiedad to, que es la página a la que enlaza. Podemos implementarlo con Props with Children, donde simplemente creamos una interfaz para las propiedades que no son children y la pasamos como argumento de tipo. Esto se ve realmente bien.

A continuación, vamos a hablar de la propagación de props. A veces también se le conoce como reflejar las props de otro componente. Un ejemplo muy simple es un botón. En el formulario de edición personalizada, tenemos dos botones en la parte inferior, cancelar y guardar. Son ligeramente diferentes, pero se implementan con el mismo componente. Podemos verlos aquí en el formulario de edición, donde los botones toman algunas propiedades predeterminadas que los botones normales tienen, como type, onClick y children, pero también algunas propiedades personalizadas, como outline e icono.

Lo que queremos lograr es especificar una interfaz que refleje todas las propiedades de un botón normal, pero que también las extienda con algunas propiedades personalizadas. Una forma bastante obvia es utilizar la interfaz button.html.attributes de React de la siguiente manera. Sin embargo, tiene la desventaja de requerir una interfaz adicional para los objetivos del controlador de eventos, donde necesitamos HTMLButtonElement del DOM. Es un poco incómodo escribir button.html y luego HTMLButton, pero funciona y es completamente funcional. Debido a la incomodidad, este enfoque no se utiliza mucho.

Una opción más común es utilizar el espacio de nombres JSX y acceder a la propiedad de elementos intrínsecos. Esto abarca todos los tipos de todos los elementos intrínsecos. Sin embargo, esto también tiene una desventaja extraña. No se puede extender directamente. Si intentas extenderlo con una interfaz, obtendrás un error de análisis de TypeScript extraño. La gramática de TypeScript simplemente no permite extender una interfaz de índice de corchete de esta manera. Podemos guardarlo en un tipo y extenderlo desde allí. Pero tenemos que pasar por ese tipo adicional. Ambos enfoques también tienen una desventaja adicional. Ambos incluyen ref porque es una propiedad válida que se puede pasar a un componente, pero nunca es una propiedad válida para recibir dentro de un componente en el objeto de props. Por lo tanto, esto sería válido en TypeScript, pero no tiene mucho sentido. Así no recibimos un ref. Por estas razones, prefiero utilizar componentes sin ref.

Los componentes sin ref requieren un nombre de elemento específico como argumento de tipo. Y se pueden extender sin problemas y no incluyen ref, lo cual es bastante obvio por su nombre. Esta interfaz realmente se puede utilizar para extraer props de cualquier componente, incluidos los personalizados, pero yo la uso principalmente para elementos HTML intrínsecos. A veces no queremos permitir los mismos elementos de las mismas propiedades para un elemento integrado.

Por ejemplo, para este campo de entrada numérica que puedes ver en acción aquí. Tiene un modelo de visualización agradable donde el número se formatea de manera diferente al perder el foco. Para lograr esto, no podemos permitir que los usuarios del componente especifiquen el tipo o el patrón, ya que eso eludiría el propósito. Implementamos esto utilizando el tipo omit-typescript. Otro truco aquí es que en realidad cambiamos el tipo de la propiedad value. En un elemento de entrada regular, value es una propiedad opcional que permite números, cadenas y indefinido. Pero en nuestro componente, es una propiedad requerida que solo permite números. Podemos hacerlo sin usar omit. No tenemos que omitirlo de la interfaz principal porque estamos estrechando el tipo. Si quieres que cambiemos el tipo a algo que no se incluyó en el original, por ejemplo, una función, tendríamos que omitirlo del original antes de cambiarlo. Estrechar está permitido al extender, pero no al cambiar. También usamos esta misma idea para eliminar solo la parte opcional de un tipo. Por ejemplo, en nuestro componente Form, queremos requerir la función unsubmit. No podemos tener eso como opcional. Queremos asegurarnos de que todos los que usen este componente siempre proporcionen una función unsubmit. Pero el tipo de esta función es un poco complejo. Podemos usar el tipo original, pero luego tenemos que indexar el original de esta manera bastante extraña. Es un poco repetitivo, especialmente si tuviéramos más de una propiedad que quisiéramos hacer de esta manera. Una mejor manera es crear un pequeño tipo de utilidad llamado Hacer Obligatorios, donde podemos usar un modificador de tipo para eliminar la parte opcional del tipo utilizando esta sintaxis de signo de interrogación menos . Esto da como resultado una interfaz mucho más limpia y ahora solo tenemos que especificar los nuevos tipos que no están en el original.

A continuación, crearemos componentes que requieren que los atributos cumplan exactamente con una de varias interfaces en una situación de opción-o. En nuestro ejemplo de tabla, tenemos la capacidad de agregar botones de acción como puedes ver aquí. Sin embargo, estos dos botones son ligeramente diferentes. Uno de ellos es un enlace y el otro es un botón con una devolución de llamada. En el componente serviceList, podemos ver aquí que especificamos siempre una etiqueta de acción, pero especificamos tanto una propiedad de enlace como una devolución de llamada onClick, pero no podemos especificar ambas, eso sería inválido. Queremos asegurarnos de escribir correctamente esto dentro de la implementación de la tabla.

Aquí vemos que action es un tipo de unión de acción de enlace o acción de clic y nuestra tabla acepta una lista opcional de acciones. Sin embargo, utilizar esto dentro del componente es un poco complejo. Tenemos que utilizar el estrechamiento de TypeScript y la forma más limpia de hacerlo es verificar si una propiedad dada existe en el valor. Si el objeto de acción contiene una propiedad de enlace, entonces probablemente sea una acción de enlace, y TypeScript lo sabe, por lo que conoce las propiedades. Si no contiene una propiedad de enlace, debe ser una acción de clic, por lo que contiene una función onClick, y TypeScript también lo sabe. Pero la verificación de la propiedad es un poco fea. Podemos moverla a un guardia de tipo y hacer lo mismo, y se ve mejor, pero sigue siendo un poco complejo. ¿Qué tal si en su lugar tuviéramos una propiedad en las diferentes interfaces de la unión que pudiera directamente discriminar entre qué miembro de la unión específica estábamos trabajando? Bueno, eso es una unión discriminada.

Tenemos otro ejemplo aquí en nuestro componente Select. Nuestro componente Select puede ser tanto una selección única como una selección múltiple, como puedes ver aquí, dos selects diferentes en el mismo formulario. La diferencia es que el valor para una selección única es un elemento único, pero para una selección múltiple es una matriz de elementos. Y para la devolución de llamada, también podemos recibir tanto un elemento único como varios elementos en la devolución de llamada. Puedes ver aquí cómo si agregamos una devolución de llamada manual a estos dos componentes, sabe directamente si recibió una cadena única o si recibe una lista de cadenas. Podemos implementar eso con dos interfaces que comparten una propiedad que nos dice directamente en qué caso nos encontramos. Esa propiedad es, por supuesto, la propiedad multiple. Podemos usar directamente esa propiedad dentro de la implementación para invocar correctamente la devolución de llamada con los argumentos adecuados. Y TypeScript sabe correctamente que la devolución de llamada acepta estos argumentos correctos. En este ejemplo solo teníamos dos opciones, por lo que se podría hacer con un booleano. Si tienes más de dos opciones, la forma más fácil es implementarlo con un tipo de cadena de unión. No necesitas una enumeración. No hay nada que una enumeración pueda darte que un tipo de cadena de unión no pueda hacer igual de bien. Solo crearías código innecesario, que es lo que hacen las enumeraciones. Así que utiliza un tipo de cadena de unión y estarás bien. Sin embargo, este select solo aceptaba cadenas y luego devolvía cadenas.

¿Qué pasaría si quisiéramos insertar un elemento arbitrario y recibir ese mismo elemento de vuelta en una devolución de llamada? Para hacer eso, necesitamos utilizar genéricos. Echemos un vistazo más de cerca a nuestra tabla anterior. Podemos ver que la tabla muestra diferentes columnas en las diferentes listas. Lo hacemos con un tipo genérico. También puedes ver aquí que en la devolución de llamada de clic para una acción, sabe exactamente qué propiedades existen en el elemento particular y esto se mapea directamente a las filas de entrada para esa misma tabla. Esto se implementa con un tipo genérico.

Restringimos el tipo genérico para que extienda un registro con un ID y, de lo contrario, simplemente usamos el tipo genérico como usaríamos cualquier tipo específico. Sin embargo, hay un pequeño detalle en React. Si memorizamos el componente y volvemos a donde usamos la acción de enlace, de repente olvidó qué tipo específico de argumento recibió. La memorización simplemente elimina cualquier tipo genérico. Por lo tanto, ahora solo tiene un tipo como un registro con un ID. No conoce ninguna de las otras propiedades. Así es como se tipa una función memo en React. Creo que está un poco roto y debería arreglarse. Pero por ahora podemos solucionarlo de dos maneras. Si este es solo un componente único que tenemos, podemos solucionarlo simplemente cambiando el tipo del componente memorizado para que sea el mismo que el tipo del componente. Es muy simple. Si tenemos que hacer esto a gran escala para varios componentes, podemos cambiar el tipo global para la función memo dentro de React. Sí, podemos hacer eso. Simplemente especificamos que el memo devuelve lo que recibe. ForwardRef tiene exactamente el mismo problema. Y eso también puede surgir en tu código. Y es un poco más complicado de tipar correctamente, pero aún puedes hacerlo de ambas maneras.

Pasemos a un tema más complejo. Contexto. Primero tenemos un contexto simple. Es nuestro proveedor de autenticación. Utilizaremos el contexto incorporado de React para servirlo. Se utiliza en el componente de inicio de sesión. Entonces, cuando presionamos el botón de inicio de sesión, invocamos la función de inicio de sesión desde el contexto.

Y eso cambia alguna bandera en algún lugar diciendo que ahora hemos iniciado sesión. En el componente raíz, enviamos al usuario a una página diferente dependiendo del estado de inicio de sesión. En el componente de inicio de sesión, invocamos el inicio de sesión desde este contexto y eso se hace al enviar el formulario. Creamos este contexto con una interfaz y el contexto de creación incorporado. Aquí también permitimos que el contexto sea nulo. Solo para poder pasar un nulo al crear el contexto. Esto hace que sea mucho más fácil crear el contexto. Tenemos un gancho personalizado para acceder al contexto que rellena con nulo. Así que sabemos que eso no va a suceder y siempre devuelve el valor del contexto. En el proveedor de autenticación, pasamos un valor con una estructura adecuada. Pero como puedes ver aquí, en realidad podríamos pasar nulo como valor en el proveedor. Romperá los consumidores ya que lanzamos una excepción en nulo, pero el sistema de tipos realmente lo permite. Si no permitiéramos nulo, tendríamos que crear el contexto compacto de una manera más compleja sin un propósito real. Aquí solo tenemos dos propiedades, pero si tuviéramos más propiedades, sería un contexto realmente largo y molesto para escribir.

A veces las personas usan parcial en su lugar, pero conduce a los mismos problemas. Por ejemplo, en el componente de inicio de sesión, tendremos que verificar si la función de inicio de sesión existía antes de poder invocarla, porque ahora es una propiedad opcional y no una propiedad requerida.

Un contexto simple como este no es útil a gran escala. Si alguna propiedad dentro del contexto cambia, todos los consumidores se vuelven a renderizar. En nuestro ejemplo anterior, el componente de inicio de sesión se vuelve a renderizar cuando iniciamos sesión, porque cambia la propiedad de inicio de sesión en el contexto, aunque no usemos esa propiedad en el componente de inicio de sesión en absoluto.

Un enfoque mejor es usar un contexto seleccionable. Hay una gran biblioteca llamada useContextSelector que nos permite hacer precisamente eso. Veamos el proveedor de API subyacente que maneja todos los datos principales para la aplicación CRUD. Esta API nos permite editar, agregar y eliminar servicios, y maneja la actualización del estado. Pero no queremos que los consumidores de contexto que no están utilizando servicios NGATE se vuelvan a renderizar solo porque agregamos un nuevo servicio.

Ahora podemos pasar una función selector. En el horario, seleccionamos una única propiedad del proveedor de API, los empleados, para poder mostrarlos todos. Pero con mayor frecuencia, seleccionamos múltiples propiedades, y para asegurarnos de que la memoria caché y el renderizado funcionen, debemos comparar superficialmente los objetos devueltos, por lo que también pasamos un indicador booleano. Veremos cómo funciona esta función selector en un momento, pero primero veamos cómo se crea el contexto.

En realidad, todavía permitimos nulo aquí para facilitar la creación del contexto. Este contexto tiene múltiples valores, por lo que si tuviéramos que escribirlos todos, sería mucho trabajo. Permitir nulo hace que sea mucho más fácil y compacto. Esto se debe a que esta library.useContextSelector todavía se requiere como un valor inicial para el contexto. En el proveedor, aplicamos el valor de la misma manera que normalmente, y también puedes ver aquí que aún se permite pasar nulo. Pero ahora las cosas se complican. Cuando seleccionamos de nuestro contexto, tenemos esta función sobrecargada. Nos permite seleccionar todo el contexto si no pasamos nada, seleccionar un solo valor si pasamos un selector, o seleccionar múltiples valores si pasamos un selector y verdadero. No es bonito. Es un poco complejo, pero funciona. Pero si necesitas esto para múltiples contextos en toda tu aplicación, es muy repetitivo copiarlo. Por esa misma razón, he creado una pequeña biblioteca llamada Recontextual que hace exactamente esto. Envuelve useContextSelector y simplifica la API. Es ligeramente parcial en cuanto a cómo debería verse la API, pero creo que esto sigue siendo muy genérico y puede ser utilizado por la mayoría de las personas. No permite un valor predeterminado, pero tampoco creo que las personas usen el valor predeterminado de contextos más complejos de todos modos. Veamos cómo lo usamos en ScheduleProvider.

Puedes verlo en acción aquí. Mostramos el horario diario en la parte inferior y en la parte superior podemos cambiar el día y también mostrar qué día es el día actual en un componente de calendario pequeño.

Entonces, en el componente de calendario aquí, seleccionamos múltiples valores del contexto, y en el horario, seleccionamos solo un valor. Esto se implementa aquí en un archivo llamado Recontextual.ts. Solo requiere el tipo de contexto, y eso es todo. Devuelve un proveedor y una función selector, y todo está cuidado.

En el proveedor, pasamos un valor, y como puedes ver aquí, en realidad no se permite nulo. Internamente usa nulo, pero no expone el hecho de que usa nulo. Así que no está permitido. Tenemos que pasar un valor adecuado. La biblioteca se encuentra aquí en GitHub y tiene un tamaño muy pequeño. Realmente espero que te guste y quieras jugar con ella.

Esos son todos mis tips. Estaré disponible para preguntas y respuestas justo después de esta charla. Si crees que cometí un error o algo extraño, o crees que simplemente estoy equivocado, por favor envíame un mensaje en LinkedIn. Ese es probablemente el mejor lugar para contactarme. Muchas gracias por escuchar, y por favor considera comprar mis libros. Gracias.