Video Summary and Transcription
Mark Erickson, un Ingeniero Frontend Senior en Replay, discute las bibliotecas de JavaScript y su soporte para TypeScript, incluyendo migración, versionado y depuración. También explora los desafíos de soportar múltiples versiones de TypeScript y diseñar APIs para su uso con TypeScript. Además, comparte trucos avanzados de tipos Redux e ideas para mantener una biblioteca TypeScript. Los resultados de la encuesta revelan el uso generalizado de TypeScript entre los desarrolladores, con muchos migrando gradualmente sus bases de código. Por último, proporciona consejos para actualizar TypeScript y verificar la funcionalidad.
1. Introducción a Mark Erickson
Hola, soy Mark Erickson, un Ingeniero Senior de Frontend en Replay, conocido por responder preguntas sobre React y Redux, recopilar enlaces útiles, escribir entradas de blog y ser un mantenedor de Redux.
Hola, soy Mark Erickson, y hoy me gustaría hablarles sobre las lecciones que he aprendido manteniendo TypeScript libraries. Un par de cosas rápidas sobre mí. Actualmente soy un Ingeniero Frontend Senior en Replay, donde estamos construyendo un verdadero depurador de viaje en el tiempo para aplicaciones JavaScript. Si no lo has visto, por favor, échale un vistazo. Soy conocido por varias cosas. Soy un respondedor de preguntas. Con gusto responderé preguntas sobre React y Redux en cualquier lugar donde haya un cuadro de texto en internet. Recojo enlaces interesantes a cualquier cosa que parezca potencialmente útil. Escribo entradas de blog extremadamente largas sobre React y Redux, y soy un mantenedor de Redux. Además, también podrías conocerme como ese tipo con el avatar de los Simpsons.
2. Bibliotecas JavaScript y Soporte TypeScript
Hoy vamos a hablar sobre las diferentes formas en que las bibliotecas JavaScript pueden usar y soportar TypeScript, cómo abordar la migración de una biblioteca JavaScript a TypeScript, problemas al tratar con los tipos de biblioteca y la versión, y soportar múltiples versiones de TypeScript también, cómo puedes depurar y probar tipos, cómo abordar el diseño de APIs para usar con TypeScript, y potencialmente algunas características que facilitarían el uso de TypeScript con bibliotecas. Los tipos sirven para varios propósitos, incluyendo la documentación de la API, la corrección del código del usuario, y la corrección del código de la biblioteca. Hay una diferencia distinta entre los tipos de aplicación y los tipos de biblioteca, siendo los tipos de biblioteca más complejos. Las bibliotecas JavaScript pueden proporcionar tipos al estar escritas en TypeScript, escribir a mano las definiciones de tipo para el código JavaScript, o usar tipos comunitarios de Definitely Typed. Las bibliotecas Redux han utilizado todos estos enfoques y han estado migrando a TypeScript. El primer paso en la migración es configurar la infraestructura de construcción y configurar las pruebas.
Hoy vamos a hablar sobre las diferentes formas en que las bibliotecas JavaScript pueden usar y soportar TypeScript, cómo abordar la migración de una biblioteca JavaScript a TypeScript, problemas al tratar con los tipos de biblioteca y la versión, y soportar múltiples versiones de TypeScript también, cómo puedes debug y probar tipos, cómo abordar el diseño de APIs para usar con TypeScript, y potencialmente algunas características que facilitarían el uso de TypeScript con bibliotecas.
Entonces, ¿por qué incluso proporcionamos tipos con una biblioteca? Los tipos sirven para varios propósitos. Uno es la documentación de la API. Los usuarios pueden mirar los tipos y entender qué funciones y tipos existen y cómo puedes usarlos en tu aplicación. Otro es la corrección del código del usuario. Pueden hacer cumplir ciertos patrones de uso que los usuarios deben tener en su aplicación fuente de código. Junto con eso, está la corrección del código de la biblioteca. Los tipos nos ayudan a asegurar que el código dentro de nuestra biblioteca se comporta como se espera, y se trata de mantenibilidad, de poder trabajar en el código real dentro de la biblioteca.
Ahora, diré que creo que hay una diferencia distinta entre los tipos que ves dentro del código de la aplicación y los tipos que ves dentro del código de la biblioteca. Los tipos de aplicación tienden a ser bastante simples. Tienes respuestas de la API, argumentos de funciones, estado con el que estás lidiando, componentes props. Por lo general, no es demasiado complicado, y no ves muchos tipos genéricos allí. Los tipos de biblioteca, por otro lado, son mucho más complicados porque necesitan manejar casos de uso mucho más flexibles. Los tipos de biblioteca tienden a tener un uso mucho más pesado de los genéricos de TypeScript. Y a veces, incluso puedes ver programación a nivel de tipo donde estás haciendo inferencias, lógica condicional, y transformaciones complejas de tipos también.
Ahora, hay varias formas en que una biblioteca JavaScript puede proporcionar tipos. El mejor enfoque es si la biblioteca está realmente escrita en TypeScript. Esto garantiza que los tipos coinciden con el comportamiento real de lo que está en el código fuente de la biblioteca, y que los tipos se actualizan cada vez que hay una nueva versión de la lib. Otra opción es escribir el código fuente en JavaScript y escribir a mano las definiciones de tipo e incluirlas en la salida publicada. Esto está bien porque los tipos todavía son mantenidos por los propios dueños de la biblioteca. Pero puedes terminar en situaciones donde hay diferencias entre lo que los tipos dicen que está en la biblioteca y lo que el código fuente realmente hace. Como último recurso, si los mantenedores de la biblioteca no quieren tener sus propios tipos, entonces la comunidad puede juntar algunos tipos y publicarlos en el repositorio Definitely Typed de Microsoft. Esto puede definitivamente llevar a problemas, pero al menos te da una forma de tener tipos, especialmente si los mantenedores de la biblioteca no quieren preocuparse por tratar con eso ellos mismos. Realmente hemos usado todos estos diferentes enfoques con las bibliotecas Redux a lo largo del tiempo. Pero hemos estado trabajando en tratar de migrar las bibliotecas Redux a TypeScript, especialmente en los últimos años. El núcleo de Redux fue convertido a TypeScript en 2019. Simplemente nunca llegamos a publicarlo. La versión 8 de React Redux finalmente se convirtió a TypeScript, y migramos Reselect el año pasado. Entonces, ¿cómo abordas una de estas migraciones? Bueno, el primer paso es configurar alguna infraestructura de construcción. Necesitas asegurarte de que estás compilando los tipos de TypeScript, transformando la salida de la construcción a JavaScript plano, y quieres asegurarte de que tu configuración de pruebas está configurada para lidiar con TypeScript también.
3. Gestión de Tipos y Versionado
Necesitas incluir los tipos en el paquete publicado directamente, probar el paquete con código TypeScript, usar typedefs existentes como punto de partida, convertir archivos a TypeScript, renombrar archivos para preservar el historial de Git, convertir pruebas a TypeScript, exportar tipos desde el archivo índice, gestionar el versionado para tipos públicos, factorizar los tipos en el versionado, dividir los cambios en rompedores y no rompedores, apuntar a versiones específicas de TypeScript, soportar versiones antiguas, adoptar nueva sintaxis y características, probar contra múltiples versiones de TypeScript.
También necesitas asegurarte de que los tipos se incluyen en el paquete publicado directamente. Eso significa agregar una clave de tipos a tu paquete JSON. Y es una buena idea probar realmente la publicación del paquete con alguna aplicación code de TypeScript y asegurarte de que las cosas funcionan como esperas. Y me gusta usar una herramienta llamada Yalk para hacer una publicación local de esto.
Cuando estés listo para convertir el code actual, si hay algún typedef existente, como indefinidamente tipado, te sugiero fuertemente que los uses como punto de partida. Hicimos eso para React Redux. Elige algunos archivos, conviértelos a TypeScript y repite. Y realmente recomiendo tener algunos commits que solo renombren los archivos primero antes de que realmente comiences a hacer cambios en ellos para tratar de preservar el historial de Git existente. Además, no olvides convertir todas tus pruebas a TypeScript. Esto ayudará a detectar algunos de los problemas, y veremos un par de otros ejemplos de esto más adelante. Finalmente, asegúrate de que realmente estás exportando tipos de tu archivo índice, no solo las funciones y las estructuras de data en el code.
Entonces, ¿cómo gestionas el versionado para tipos públicos? Esto es un poco complicado. TypeScript en sí mismo no utiliza el semantic versioning. Simplemente utilizan un enfoque de incremento decimal, y eso significa que cualquier nueva versión de TypeScript podría, de hecho, romper el code que se está ejecutando actualmente. Además de eso, diferentes personas pueden tener diferentes configuraciones de TypeScript, y esas pueden llevar a diferencias en el comportamiento. Una de las cosas más grandes que vemos es que las personas desactivan las banderas de comprobación estricta o nula y esto lleva a un comportamiento de compilación claramente diferente. Realmente, cualquier cambio en tus tipos en absoluto, incluyendo para correcciones de errores, podría resultar en que las aplicaciones de los usuarios fallen al compilar.
Entonces, ¿eso significa que cada vez que lanzo una corrección de errores, esto es en realidad algún tipo de versión mayor? El equipo de Ember ha estado trabajando en tratar de establecer un conjunto de reglas para cómo planean manejar TypeScript en el ecosystem de Ember, y publicaron un RFC increíblemente extenso donde intentaron definir qué significa Sember para los tipos de TypeScript, no solo para Ember, sino un enfoque que cualquier biblioteca puede usar. Y lo que concluyeron es que los tipos son APIs. Deberías factorizar los tipos en tu versionado, pero puedes dividirlo en cambios que se consideran rompedores y cambios que se consideran no rompedores. Y hacen algunas excepciones allí para las correcciones de errores y la intención. Es posible que hagan un cambio que introduzca algunos errores en el code del usuario, pero en realidad está previniendo el mal uso de ciertos patterns en el terreno del usuario. Pero ciertamente su objetivo es que si sigues la lista de versiones soportadas de TypeScript, no deberías ver nuevos errores apareciendo en el code del usuario. Otro problema relacionado es cómo apuntas a versiones específicas de TypeScript. TypeScript saca varias versiones nuevas al año y esas pueden tener nuevas características y funcionalidades bastante importantes. Entonces, ¿cuánto tiempo soportas versiones antiguas de TypeScript? ¿Qué tan pronto puedes adoptar nueva sintaxis y características? ¿Y cómo te acercas a las testing contra múltiples versiones de TypeScript? Vale la pena mencionar que el repositorio Definitely Typed en sí mismo intenta soportar aproximadamente 2 años de versiones de TypeScript. Entonces, diferentes bibliotecas abordan esto de diferentes maneras. Ember ha definido su conjunto de planes de adopción donde han dicho que las bibliotecas centrales de Ember usarán una ventana rodante donde intentarán soportar nuevas versiones de TypeScript de inmediato y dejarán de soportar versiones antiguas en versiones de soporte a largo plazo de Ember. Otras bibliotecas de Ember podrían simplemente elegir un par de versiones. Y cada vez que dejan una versión se considera un lanzamiento mayor de esa biblioteca.
4. Soporte para Múltiples Versiones de TypeScript
Para soportar múltiples versiones de TypeScript, configura tu CI para construir y probar tu aplicación contra diferentes versiones de TypeScript. Usa una versión más antigua de TypeScript durante el desarrollo para restringirte a la sintaxis compatible con esa versión.
El grupo Stately, por otro lado, ha dicho que nos reservamos el derecho de hacer cambios en nuestro soporte para TypeScript a medida que nuestra comprensión de TypeScript y su comportamiento evoluciona con el tiempo. Entonces, ¿cómo puedes soportar múltiples versiones de TypeScript? Lo más importante que veo aquí es configurar tu CI para construir tus pruebas y tu aplicación y probarlas contra múltiples versiones de TypeScript a la vez. Esto se puede hacer utilizando algo como el soporte de Matrix en GitHub Actions. También podría ser útil usar una versión más antigua de TypeScript mientras realmente estás desarrollando en la biblioteca porque esto te obliga a restringirte a qué sintaxis puedes usar.
5. Manejo de Múltiples Versiones de TypeScript
TypeScript tiene soporte incorporado para usar múltiples copias de definiciones de tipo basadas en la versión de TypeScript del usuario. Se recomienda soportar múltiples versiones de TypeScript en tus tipos principales. Las bibliotecas 3DX hacen un esfuerzo para soportar múltiples versiones, teniendo en cuenta la intención al hacer cambios en los tipos. El número de versiones de TypeScript soportadas depende de las características necesarias, normalmente las últimas cuatro o cinco versiones. La documentación de las versiones soportadas podría mejorarse.
puedes usar realmente mientras trabajas en el code. TypeScript tiene soporte incorporado para usar múltiples copias de definiciones de tipo basadas en qué versión de TypeScript tiene el usuario en su aplicación. Si defines un campo de versiones de tipos, puedes apuntar a TypeScript a una comparación y a archivos de definición de tipos específicos, y los usará en su lugar si es una versión más antigua de TypeScript. También es posible de alguna manera compilar hacia atrás algunas definiciones de tipo para trabajar en versiones más antiguas de TypeScript. En la práctica, sin embargo, sugiero usar versiones de tipos como último recurso. Idealmente, tus tipos principales deberían soportar varias versiones a la vez. Entonces, ¿cómo manejamos esto con las bibliotecas 3DX? En realidad no tenemos una política de versionado específica que hayamos escrito. En general, intentamos hacer un esfuerzo de buena fe para tratar de soportar varias versiones de TypeScript a la vez. Y tenemos en cuenta la intención cuando hacemos cambios en los tipos. Como, si hago un cambio que técnicamente introduce nuevos 'red squigglies', pero mi intención era que estoy arreglando un bug, entonces lo lanzaría como una versión de parche en lugar de una versión mayor. Ha habido un par de veces en las que hemos publicado cambios que técnicamente rompían, pero solo después de que hice una búsqueda de uso público de code y vi que nadie está realmente usando este tipo en la práctica. Tampoco tenemos una definición estrictamente definida para cuántas versiones de TypeScript soportamos. En la práctica, tiende a ser las últimas cuatro o cinco versiones, así que aproximadamente un año de lanzamientos de TypeScript. Realmente depende de qué características necesitamos.TypeScript 4.1 en particular fue realmente grande porque introdujo un montón de nuevas características de cadena. Nos apoyamos en eso para cosas como las APIs de hooks de consulta RTK. También, francamente, no hacemos un buen trabajo documentando qué versiones de TypeScript soportamos actualmente, y eso es algo en lo que podríamos mejorar. Aunque al menos he intentado listar qué cuando estamos dejando de soportar una versión en las notas de la versión.
6. Depuración de Tipos y Diseño de APIs
Los tipos de Typescript pueden tener errores, por lo que los usuarios deben proporcionar reproducciones de los problemas. Diferentes configuraciones y configuraciones pueden causar variaciones en el comportamiento del tipo, especialmente cuando se desactivan las banderas estrictas o de verificación nula. La depuración de tipos no es fácil, pero puedes ajustar la configuración de VS Code y utilizar el tipo Any.compute en la biblioteca TS Tool Build. Probar los tipos en tu biblioteca es crucial, y las utilidades en las bibliotecas de Redux pueden ayudar con esto. TypeScript empuja hacia diseños de API más simples, como se ve en la API de Hooks de React Redux.
Como los tipos son code, eso significa que tienen errores, y los usuarios informarán muchos y muchos problemas con los tipos de TypeScript. Y eso significa que necesitamos que los usuarios proporcionen reproducciones de esos problemas, y esto es especialmente cierto porque diferentes usuarios pueden tener diferentes configuraciones y diferentes configuraciones. Así que, como mínimo, necesitas saber qué versión de TypeScript estás usando y cómo la tienen configurada, y esto realmente significa que los usuarios necesitan suministrar cajas de arena o repositorios de GitHub o enlaces al patio de recreo de TypeScript que muestren este tipo de error ocurriendo. Uno de los mayores problemas que vemos es casos en los que la gente ha desactivado las banderas estrictas o de verificación nula, y esto realmente introduce diferencias en cómo se comportan nuestros tipos. Así que en este punto, les decimos a los usuarios, si estableces eso en falso, ese es tu problema, no el nuestro.
Desafortunadamente, realmente no hay una buena manera de debug los tipos muy fácilmente. No puedes poner un punto de interrupción en medio de una definición de tipo y detenerte a ver qué está calculando actualmente TypeScript. Además, si estás pasando el ratón sobre las variables en VS Code, muchas veces limita el tamaño de salida por defecto. Hay un par de formas de ajustar esto. Puedes cambiar la bandera de no truncamiento de errores en tu configuración de TS, o puedes sumergirte en el code de TypeScript y alterar el valor codificado para cuánta salida muestra en el hover en VS Code. Una sugerencia es que si tienes algunos tipos complejos, recrea esos paso a paso y asígnalos a variables de tipos separadas e intenta ver qué está haciendo en cada paso del camino. También hay un tipo en la biblioteca TS Tool Build llamado Any.compute que puede hacer algunas expansiones recursivas de tipos. Es muy importante que intentes probar los tipos en tu biblioteca y tenemos archivos de prueba de tipos en las bibliotecas de Redux. Y esto es realmente solo code de TypeScript que necesita compilar limpiamente y tiene algunas afirmaciones en allí que dice que espero que esta variable sea un cierto tipo. Puedes escribir estos como archivos de prueba simples que se ejecutan a través de TSC. Puedes tenerlos como pruebas omitidas en una suite de pruebas. Pero la idea es que quiero saber ¿este code compila limpiamente? Y hemos creado muchas utilidades en las bibliotecas de Redux para cosas como esperar que ciertos tipos existan. Así que cuando se trata de diseñar APIs, el problema es que JavaScript es un lenguaje muy dinámico. Y TypeScript intenta capturar ese comportamiento y no siempre funciona bien. Así que en general, TypeScript nos empuja a design APIs que son mucho más simples. Y un buen ejemplo de esto es React Redux. La API Connect original es muy dinámica. Toma cuatro parámetros diferentes, todos muy opcionales, algunos de los cuales pueden ser objetos o funciones o nulos. Es increíblemente complicado y las diferencias de tipo para esto son extrañas, francamente. Y nuestra API de Hooks es mucho más simple. UseSelector es solo una función que toma una entrada conocida y devuelve un resultado. Es más simple de escribir. Es más simple para la gente usar. Intentamos design las APIs de React Redux y Redux toolkit de manera que puedan inferir tanto como sea posible. Queremos que nuestros usuarios tengan que suministrar la menor cantidad posible de información para obtener
7. Trucos Avanzados de Tipos Redux
Nuestros tipos pueden ser complicados, pero facilitan la vida de los usuarios. Proporcionar tipos predefinidos puede ser útil. Las bibliotecas Redux utilizan tipos condicionales y comparaciones x extends y. Las ternarias anidadas pueden ser difíciles de leer pero a veces son necesarias. Redux Toolkit tiene tipos para diferentes escenarios, incluyendo creadores de acciones y createAsyncThunk. En createAsyncThunk, se proporcionan valores predeterminados para tipos opcionales. Reselect tiene un tipo complejo que maneja entradas variadas. Los genéricos opcionales o nombrados ayudarían a los mantenedores en el futuro.
el comportamiento correcto del tipo. Eso significa que nuestros tipos son más complicados como resultado, pero facilita la vida de nuestros usuarios. Ahora, a veces no puedes realmente saber los tipos finales que un usuario va a necesitar proporcionar en las definiciones de funciones o tipos del núcleo. Por lo tanto, a veces es necesario proporcionar un tipo que un usuario puede importar, y sobrescribir, y pasar valores como el estado final de Redux en su aplicación. Por lo tanto, tener estos tipos predefinidos que pueden usar con su code puede ser muy útil.
Entonces, veamos algunos tips y trucos diferentes de las diversas bibliotecas Redux. Verás muchos tipos condicionales allí, y los tipos condicionales son básicamente comparaciones a nivel de tipos y operadores ternarios. Y verás mucho de x extends y allí, y esto es tanto una comparación como una comprobación de si este tipo cumple con este criterio. Puedes, al igual que el verdadero code, anidar estas declaraciones ternarias. Un buen ejemplo de esto es el middleware de thunk para el tipo de la tienda de configuración de Redux Toolkit, donde estamos intentando averiguar qué tipo debe incluirse para el middleware de thunk en la configuración de la tienda basada en las opciones que el usuario ha proporcionado. Así que si dijeron que el middleware de thunk debería estar apagado, entonces no queremos incluir un tipo para el middleware en absoluto. Si incluyeron un argumento extra, necesitamos usar eso. De lo contrario, se recurre al tipo predeterminado. O el tipo de acción de carga, donde sabemos que queremos empezar con un campo de carga y un tipo de campo, pero también podría haber un campo meta o un campo de error, dependiendo de cómo se definió el creador de la acción. Ahora, es cierto que las ternarias pueden ser difíciles de leer. Nunca he sido un fan de las ternarias anidadas. Y desafortunadamente, en TypeScript, a veces tienes que hacer lo que tienes que hacer. Y sí, esto puede salirse un poco de las manos. Este tipo representa todas las posibles formas en que un creador de acciones de Redux Toolkit podría ser definido con todos los campos opcionales y que pueden ser pasados a través. Bueno. Sí. A veces esto realmente se pone ridículo. Como este tipo que representa un creador de acciones createAsyncThunk. Si piensas que esto es realmente difícil de leer, sí, estoy completamente de acuerdo. Ahora, un truco que sí utilizamos en createAsyncThunk es proporcionar algunos valores predeterminados para varios tipos opcionales y dar a los usuarios una forma de anular estos. Idealmente, todo lo que hacen es proporcionar un tipo para el argumento de entrada y el tipo de retorno. Todo se infiere a partir de ahí. Si necesitas anular algo como el valor del estado para usar con getState, entonces puedes anular condicionalmente solo ese y dejar los otros campos como dispatch y extra solos. En reselect, tenemos un tipo increíblemente complejo que hace un montón de mapeo a nivel de tipos y transposición y extracción. Me llevó semanas llegar a este tipo y tuve que obtener mucha ayuda de otras personas, pero esto nos ahorró más de 3000 líneas de tipos definidos múltiples veces para manejar de 1 a 12 entradas variadas. Esto requirió muchos trucos como usar valores predeterminados para genéricos para básicamente precalcular algunas variables o mapear sobre tuplas y asegurarse de que solo usamos campos numéricos. Entonces, ¿qué tipo de cosas ayudarían a los mantenedores en el futuro? De lejos, la cosa más grande es
8. Mantenimiento de una Biblioteca TypeScript
Especificar uno o dos genéricos en lugar de todos ellos a la vez haría nuestra vida más fácil. Serían útiles mejores formas de depurar o visualizar tipos y especificar mensajes de error para los tipos. El compilador de TypeScript necesita emitir mejores mensajes de error. Miembros del equipo de TypeScript han propuesto formas de mejorar esto.
genéricos opcionales o nombrados. Esto haría nuestra vida mucho más fácil si pudiéramos simplemente especificar uno o dos genéricos en lugar de todos ellos a la vez. Además, mejores formas de debug o visualizar tipos a medida que fluyen a través del sistema de tipos. También podría ser útil realmente especificar mensajes de error para los tipos, de modo que cuando los usuarios tienen una entrada específicamente mala entonces podemos definir cuáles deberían ser los mensajes de error. Tener algunas comparaciones de tipos incorporadas sería útil, y francamente el compilador de TypeScript necesita emitir mejores mensajes de error. Y ha habido algunas propuestas de miembros de el equipo de TypeScript sobre formas en las que podrían hacer esto. Así que espero que esto te dé algunas ideas de lo que es mantener una biblioteca de TypeScript y algunos de los tips y trucos con los que lidiamos para manejar ejemplos del mundo real. Si tienes alguna pregunta sobre esto, no dudes en hablar con nosotros en el chat después o pasar por los canales de Redux en el Discord de Reactiflix.
9. Discusión sobre los Resultados de la Encuesta
Los resultados de la encuesta muestran que un número significativo de los encuestados en la conferencia de TypeScript utilizan TypeScript entre el 51 y el 90 por ciento, mientras que el 30 por ciento lo utiliza el 100 por ciento del tiempo. Sorprendentemente, el 14 por ciento de los encuestados utilizan TypeScript el 0 por ciento, lo que indica un deseo de aprender. Estos resultados reflejan la naturaleza transicional de las aplicaciones, con muchos desarrolladores migrando gradualmente sus bases de código. Como alguien que tiene experiencia con esto, encuentro los resultados esperados y comprensibles.
Gracias, y que tengas un buen día. Hola Mark, bienvenido. Vamos a discutir los resultados de la encuesta. Básicamente, el 50 al 90 por ciento, el 32 por ciento, utiliza TypeScript entre el 51 y el 90 por ciento. Luego, el 30 por ciento de los encuestados utiliza TypeScript el 100 por ciento todo el tiempo, el 24 por ciento solo un poco, entre el 1 y el 50 por ciento. Y me sorprende mucho descubrir que el 14 por ciento de todos los que responden utilizan TypeScript el 0%, lo cual es bastante interesante porque es una conferencia de TypeScript. Pensaría que todos nosotros tendríamos algún uso y nos moveríamos un poco. Pero no, hay un 14 por ciento que tiene 0. Tal vez solo quieren aprender. ¿Qué piensas sobre estos resultados de la encuesta en general? Creo que tiene sentido. Quiero decir, dado que es una conferencia de TypeScript, esperarías que mucha gente estuviera utilizando una buena cantidad de TypeScript real code. Pero creo que esto habla de la naturaleza muy transicional de nuestras aplicaciones. La mayoría de nosotros no estamos en una posición en la que podamos escribir una nueva base de code de TypeScript todo el tiempo desde cero. Muchos de nosotros estamos lidiando con aplicaciones que, en muchos casos, han existido durante años. Y entonces tienes, ya sabes, gente que está tratando de migrar sus bases de code de forma gradual. He hecho una cantidad significativa de eso a lo largo de mi career. Así que estoy muy familiarizado con esa idea.
10. Actualización de TypeScript y Verificación de Funcionalidad
Si se actualiza la versión de TypeScript en un proyecto que no es de biblioteca, deberías poder aumentar TypeScript y posiblemente reiniciar VS code para asegurarte de que el servidor de lenguaje está analizando las cosas correctamente. También es importante volver a ejecutar un paso de compilación y compilar todo el proyecto para verificar su funcionalidad.
Genial. Gracias. Así que tenemos un par de preguntas para ti. Anil Polt, él está preguntando si estoy creando la versión de TypeScript como un proyecto que no es de biblioteca, ¿sería fácil simplemente actualizar y buscar un script rojo que podría aparecer si el servidor de lenguaje está funcionando correctamente? Perdona, repite eso una vez más. Sí, por supuesto. Si la actualización de la versión de TypeScript es un proyecto que no es de biblioteca, ¿sería fácil simplemente actualizar y buscar un nuevo script rojo que podría aparecer si el servicio de lenguaje está funcionando correctamente? Veamos. Creo que en general, en su mayor parte, deberías poder aumentar TypeScript. He descubierto que como regla general tanto en el desarrollo de aplicaciones como en el desarrollo de bibliotecas, definitivamente hay momentos en los que tengo que entrar y usar el comando VS code para reiniciar el servidor de TypeScript o simplemente recargar toda la ventana, es la vieja historia de reiniciar y ver qué pasa y ver si funciona mejor para asegurarme de que TypeScript está analizando las cosas correctamente, especialmente si estás haciendo algo como actualizar la versión de TypeScript o a veces modificar otras versiones de bibliotecas que tienes en la aplicación. Pero en general, aumentar esas cosas y posiblemente reiniciar debería ser suficiente para que VS code y el servidor de lenguaje comiencen a hacer algún reprocesamiento. Ahora, como observación general, también he visto que solo porque VS code está limitado generalmente a solo los archivos que tienes abiertos y hay muchos archivos que en realidad no tienes abiertos. Así que mirar las cosas en el editor ayuda, pero también vas a querer realmente volver a ejecutar un paso de compilación y hacer que intente compilar todo el proyecto para ver si realmente está funcionando de la manera que crees que debería. Vale, gracias. ¿Cuál es la etiqueta de TypeScript más complicada en la que has trabajado? Probablemente sería la que está en la penúltima diapositiva que hice en mi presentación de Reselect 4.1. Para punto de comparación creo que lo mencioné en la charla, los tipos de Reselect anteriores tenían definiciones escritas a mano para cubrir casos de 1 a 12 entradas como argumentos separados o un array de argumentos, y eso sumó más de 3,000 líneas solo de tipos. Así que cuando, los tipos en Reselect 4.1 comenzaron como un PR de otra persona. Así que no escribí todo desde cero, pero hice el trabajo de intentar integrarlos y luego evolucionarlos. Y ese último tipo que viste allí, donde está haciendo como una operación de mapeo a nivel de tipo, eso fue realmente difícil. Y me atribuiré la mayor parte de ello. Vi lo que quería hacer a nivel de tipos. Pero también es cierto que había un montón de lugares donde realmente no sabía cómo hacer que los tipos hicieran lo que me gusta. Puedo ver lo que necesita hacer. Si esto fuera JavaScript code, podría hacer que sucediera. ¿Cómo hago esto como una operación a nivel de tipos? Y afortunadamente, había algunas personas que eran mucho mejores en TypeScript que yo, que pudieron ayudarme a superar esos problemas. Eso fue realmente difícil de trabajar. Gracias por compartir tu experiencia. Y si alguno de los asistentes quiere compartir su experiencia sobre el tipo más difícil que han encontrado, pueden usar el hashtag TSCongress en Twitter. Y otra pregunta es, ¿cuál es el problema más común que ves cuando los usuarios presentan problemas relacionados con TS? Diría que tiene que ver con personas que no tienen la opción de configuración estricta de TypeScript o la opción de comprobación estricta de nulos activada. Hemos tenido un montón de casos en los varios repositorios relacionados con Redux donde alguien presenta un problema diciendo, la biblioteca no funciona correctamente en mi aplicación. Y siempre, como mantenedores, siempre pedimos a alguien que nos muestre una reproducción de un problema como un code sandbox o un repositorio de GitHub. Pero esto es especialmente cierto cuando es un problema de TypeScript porque hay tantas diferentes opciones de configuración que podrían haber establecido de manera diferente. Y hemos visto un montón de casos donde resulta que el usuario no tenía activada la comprobación estricta de nulos, y eso significa que los tipos que hemos escrito en nuestra biblioteca se están comportando de manera diferente a cómo nosotros mismos los probamos y esperamos que funcionen. Y en ese caso, en realidad les decimos, mira, francamente, desde nuestra perspectiva, la configuración de tu aplicación está mal. Por favor, activa la comprobación estricta de nulos y eso solucionará el problema real que estás viendo. Vale. Gracias. Eso fue genial. Así que ahora vamos a unirnos a Mark en la sala de conferenciantes en Discord. El enlace para unirse está en la línea de tiempo. Gracias, Mark. Gracias. Lo aprecio.
Comments