7 Patrones de TypeScript que Deberías Estar Utilizando

Spanish audio is available in the player settings
Rate this content
Bookmark

En esta charla, repasaremos una serie de patrones de TypeScript comunes, útiles y probados como mejores prácticas para utilizar en React 18. Esto incluye cómo tipar correctamente las propiedades de los componentes, los tipos de retorno y los children, utilizando los tipos incorporados de React, tipando contextos y la típica diatriba sobre los enums (pero de manera constructiva).

19 min
06 Jun, 2023

Video Summary and Transcription

Esta charla presenta 7 patrones esenciales de TypeScript para el desarrollo de React, que incluyen children, spreading props, either-or, componentes genéricos y contextos. El orador demuestra diversas implementaciones y proporciona ejemplos utilizando una aplicación ficticia de una peluquería canina. Otras ideas interesantes incluyen el uso de omit y make required types, la creación de componentes con interfaces either-or, y el uso de genéricos, memorización y contextos en React. El orador también presenta la biblioteca Recontextual para la gestión de contextos.

Available in English

1. Introducción a los patrones de TypeScript en React

Short description:

¿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? Hoy, estoy aquí para 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 soy un entusiasta de React y TypeScript. Soy el autor de 2 libros sobre React. Sígueme en LinkedIn y suscríbete a mi boletín en mortenbaklund.com para obtener más consejos y trucos.

¿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.

2. Introducción a los Patrones de Componentes en React

Short description:

En esta parte, cubriremos siete patrones esenciales de TypeScript para el desarrollo de React. Estos patrones incluyen children, spreading props, either-or, componentes genéricos y contexto. Exploraremos diferentes variaciones e implementaciones, incluso sacrificando la correcta codificación de React para ilustrar puntos clave. Además, trabajaremos con una aplicación llamada Waxville, un salón de aseo ficticio para perros, para demostrar los patrones. La aplicación está disponible en GitHub y waxville.org, pero ten en cuenta que solo almacena datos en memoria y es únicamente con fines ilustrativos.

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.

3. Patrón Children en React

Short description:

El primer patrón que discutiremos es children. Es una propiedad especial que debe ser tipada correctamente para permitir diferentes tipos de contenido hijo. Podemos usar la interfaz props with children del paquete react para asegurar una tipificación correcta. Este enfoque es más transparente y elimina la necesidad de interfaces personalizadas cuando no hay props adicionales. También podemos manejar fácilmente otras propiedades creando una interfaz para las props que no son children.

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.

4. Propagación de Props en React

Short description:

A continuación, discutiremos la propagación de props, también conocida como reflejar las props de otro componente. Podemos lograr esto especificando una interfaz que refleje todas las propiedades de un botón normal y, al mismo tiempo, extenderlo con propiedades personalizadas. Existen diferentes enfoques para lograr esto, como utilizar la interfaz button.html.attributes o utilizar el espacio de nombres JSX. Sin embargo, ambos enfoques tienen inconvenientes, como una escritura incómoda o incluir la propiedad ref. Para superar estos problemas, prefiero utilizar componentes sin ref, que se pueden extender y no incluyen ref. Este enfoque nos permite extraer props para cualquier componente, incluidos los personalizados.

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.

5. Patrones de TypeScript: Omitir y Hacer Obligatorios

Short description:

Para lograr un modelo de visualización agradable para un campo de entrada numérica, utilizamos el tipo omit-typescript y cambiamos el tipo de la propiedad value. Podemos estrechar el tipo sin omitirlo de la interfaz principal. Para el componente Form, utilizamos el tipo de utilidad Hacer Obligatorios para eliminar la parte opcional del tipo y asegurarnos de que la función unsubmit sea obligatoria.

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.

6. Componentes con Interfaces de Opción-o

Short description:

A continuación, crearemos componentes que requieren atributos que cumplan con una acción de enlace o una acción de clic. Utilizaremos el estrechamiento de TypeScript para determinar el tipo de acción en función de las propiedades presentes en el valor. Además, exploraremos las uniones discriminadas y cómo se pueden utilizar para crear componentes que pueden ser de selección única o de selección múltiple, con devoluciones de llamada correspondientes que aceptan elementos individuales o matrices de elementos. También discutiremos los beneficios de utilizar tipos de cadena de unión en lugar de enumeraciones para casos con más de dos opciones.

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.

7. Generics, Memorización y Contexto en React

Short description:

Para insertar un elemento arbitrario y recibirlo de vuelta en una devolución de llamada, utilizamos genéricos. La tabla muestra diferentes columnas en diferentes listas, implementadas con un tipo genérico. Sin embargo, al memorizar componentes, se pierde el tipo específico del argumento. Podemos solucionar esto cambiando el tipo del componente memorizado o el tipo global para la función memo. El contexto es un tema más complejo, donde utilizamos el contexto incorporado de React para servir nuestro proveedor de autenticación en el componente de inicio de sesión.

¿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.

8. Creando Contexto en React

Short description:

Al crear un contexto en React, permitir que el contexto sea nulo puede facilitar el proceso. Sin embargo, pasar nulo como valor en el proveedor puede romper los consumidores. Si no se permite nulo, la creación del contexto se vuelve más compleja. Es tedioso escribir el contexto con múltiples propiedades.

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.

9. Usando Contexto Seleccionable y Biblioteca Recontextual

Short description:

A veces las personas usan parcial en su lugar, pero conduce a los mismos problemas. Un enfoque mejor es usar un contexto seleccionable. Hay una gran biblioteca llamada useContextSelector que nos permite hacer precisamente eso. Ahora podemos pasar una función selector. Cuando seleccionamos de nuestro contexto, tenemos esta función sobrecargada. No es bonito. Es un poco complejo, pero funciona. Por esa misma razón, he creado una pequeña biblioteca llamada Recontextual que hace exactamente esto. Envuelve useContextSelector y simplifica la API. Veamos cómo lo usamos en ScheduleProvider.

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.

10. Usando la Biblioteca Recontextual para la Gestión de Contexto

Short description:

Mostramos el horario diario y un componente de calendario pequeño. El componente de calendario selecciona múltiples valores del contexto, mientras que el horario selecciona un solo valor. La implementación se encuentra en un archivo llamado Recontextual.ts. La biblioteca, ubicada en GitHub, tiene un tamaño pequeño. Si tienes algún comentario, por favor envíame un mensaje en LinkedIn. ¡Gracias por escuchar!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.
Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
The more you keep working on an application, the more complicated its routing becomes, and the easier it is to make a mistake. ""Was the route named users or was it user?"", ""Did it have an id param or was it userId?"". If only TypeScript could tell you what are the possible names and params. If only you didn't have to write a single route anymore and let a plugin do it for you. In this talk we will go through what it took to bring automatically typed routes for Vue Router.
TypeScript Congress 2023TypeScript Congress 2023
31 min
Making Magic: Building a TypeScript-First Framework
I'll dive into the internals of Nuxt to describe how we've built a TypeScript-first framework that is deeply integrated with the user's IDE and type checking setup to offer end-to-end full-stack type safety, hints for layouts, middleware and more, typed runtime configuration options and even typed routing. Plus, I'll highlight what I'm most excited about doing in the days to come and how TypeScript makes that possible not just for us but for any library author.
React Advanced Conference 2021React Advanced Conference 2021
6 min
Full-stack & typesafe React (+Native) apps with tRPC.io
Top Content
Why are we devs so obsessed with decoupling things that are coupled nature? tRPC is a library that replaces the need for GraphQL or REST for internal APIs. When using it, you simply write backend functions whose input and output shapes are instantly inferred in your frontend without any code generation; making writing API schemas a thing of the past. It's lightweight, not tied to React, HTTP-cacheable, and can be incrementally adopted. In this talk, I'll give a glimpse of the DX you can get from tRPC and how (and why) to get started.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Workshop
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
TypeScript Congress 2023TypeScript Congress 2023
131 min
Practice TypeScript Techniques Building React Server Components App
Workshop
In this hands-on workshop, Maurice will personally guide you through a series of exercises designed to empower you with a deep understanding of React Server Components and the power of TypeScript. Discover how to optimize your applications, improve performance, and unlock new possibilities.
 
During the workshop, you will:
- Maximize code maintainability and scalability with advanced TypeScript practices
- Unleash the performance benefits of React Server Components, surpassing traditional approaches
- Turbocharge your TypeScript with the power of Mapped Types
- Make your TypeScript types more secure with Opaque Types
- Explore the power of Template Literal Types when using Mapped Types
 
Maurice will virtually be by your side, offering comprehensive guidance and answering your questions as you navigate each exercise. By the end of the workshop, you'll have mastered React Server Components, armed with a newfound arsenal of TypeScript knowledge to supercharge your React applications.
 
Don't miss this opportunity to elevate your React expertise to new heights. Join our workshop and unlock the potential of React Server Components with TypeScript. Your apps will thank you.
TypeScript Congress 2022TypeScript Congress 2022
116 min
Advanced TypeScript types for fun and reliability
Workshop
If you're looking to get the most out of TypeScript, this workshop is for you! In this interactive workshop, we will explore the use of advanced types to improve the safety and predictability of your TypeScript code. You will learn when to use types like unknown or never. We will explore the use of type predicates, guards and exhaustive checking to make your TypeScript code more reliable both at compile and run-time. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Are you familiar with the basics of TypeScript and want to dive deeper? Then please join me with your laptop in this advanced and interactive workshop to learn all these topics and more.
You can find the slides, with links, here: http://theproblemsolver.nl/docs/ts-advanced-workshop.pdf
And the repository we will be using is here: https://github.com/mauricedb/ts-advanced
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.