Tipos más allá de TypeScript

¿Qué son los tipos? Para responder a esa pregunta, tenemos que preguntar, ¿qué es TypeScript? En orden para responder a esa pregunta, tenemos que preguntar, ¿qué es JavaScript? En su núcleo, JavaScript es esto. JavaScript es una sintaxis junto con una especificación vaga sobre cómo ejecutar esta sintaxis. Esto es encantador. Miren esto. Tenemos un let cosa. Solíamos no tener let. Solíamos tener var. Tenemos la capacidad de asignar una variable a diferentes valores. El problema con esto, sin embargo, es que no hay una forma incorporada en JavaScript para declarar la intención detrás de esos valores. La intención detrás de esos valores. No hay una pequeña cosa que puedas poner ahí para decir que esto solo va a ser, digamos, una cadena. Y eso es problemático porque el código se vuelve realmente difícil de trabajar a gran escala. Una vez que pasas de cinco desarrolladores, 50 desarrolladores, 500 desarrolladores, se vuelve realmente difícil de manejar eso. Es por eso que tenemos TypeScript.

TypeScript agrega una sintaxis sobre JavaScript. Es un superset, lo que significa que es todo JavaScript más estas cosas nuevas, y esa sintaxis nos permite decir explícitamente no solo cuáles son los valores, sino la intención detrás de esos valores. En este caso, cadena. Ahora, porque tenemos la sintaxis de TypeScript, podemos hacer cosas como el verificador de tipos de TypeScript. Dato curioso, escrito en TypeScript, y eso es una CLI o API a la que puedes llamar para obtener pequeñas quejas que dicen, hey, dijiste que esto iba a ser una cadena, pero le diste un número, tonto. Eso no está permitido. Puedes ejecutar el verificador de tipos a través de los servicios de lenguaje para TypeScript, como VS Code, grandes editores, y te darán las mismas quejas pero en forma de líneas onduladas rojas, tipo número no asignable a cadena. Y eso es realmente útil. Es tan útil que surge la pregunta, ¿por qué no tenemos otros TypeScripts? ¿Por qué TypeScript es la única herramienta que parece estar en uso popular hoy en día para hacer cumplir los tipos en el código JavaScript? No que haya dicho popular. Hay otras herramientas, pero TypeScript tiene la mayor cuota de mercado. Ahora hay tres ejemplos de herramientas que están en el mismo espacio que TypeScript pero no son tan populares como él, y quiero repasarlos rápidamente. Primero, solo por curiosidad, ¿quién aquí usó Flow en algún momento? Una buena cantidad de nosotros. Flow es muy parecido a TypeScript. Es de Facebook, pero ha tomado una dirección diferente a TypeScript. Aún está en desarrollo activo. Pero en lugar de obtener mucho uso y volverse mundial y hacer que todos los que alguna vez hayan querido usar tipos puedan usarlo, Flow es un poco más específico.

Es más para el estilo de casos de uso de Facebook. Se ha divergido un poco, lo que significa que ha perdido popularidad en comparación con TypeScript. Ahora mencioné que TypeScript está escrito en TypeScript. Eso significa que se ejecuta a velocidades de JavaScript. Sería genial si pudiéramos ejecutar a velocidades de Rust, a velocidades de código nativo, que es lo que era el proyecto STC, pero ese proyecto fue abandonado porque resulta que es realmente difícil reimplementar TypeScript en un nuevo lenguaje. Ezno es un proyecto en curso que intenta reescribir una versión de un lenguaje similar a TypeScript en Rust, pero está llevando tiempo. Entonces, entre Flow siendo muy moderno, STC siendo abandonado y Flow, perdón, Ezno estando en progreso, por ahora estamos un poco atrapados con TypeScript, para bien o para mal. Lo que significa que esta charla trata realmente sobre tipos. Les estoy hablando sobre tipos, y es una coincidencia que esté usando TypeScript para eso. Pero realmente quiero enfocarme en eso. Esta charla trata sobre tipos. TypeScript resulta ser el detalle de implementación de cómo estamos escribiendo y usando los tipos.

¡De acuerdo! ¿Nueva charla? ¿Tipos? Sí. Muy bien. Muy bien. Pensemos en tipos y TypeScript. En primer lugar, ¿por qué nos gustan? Me gusta pensar en ellos como un pegamento de información que ayuda a fusionar o un puente que une diferentes límites del sistema o partes de tu aplicación. Supongamos que tienes un nuevo componente. Tienes ese cursor parpadeante. ¿Qué diablos se supone que debes hacer con esto? ¿Leer el código fuente? No, normalmente usarías el autocompletado de TypeScript o las definiciones de tipos, los pequeños desplegables en tu editor, para descubrir, ah, alguien escribió que hay algunas props para este componente. Eso es realmente útil. Y luego, si te equivocas, TypeScript te ayuda, te informa, oye, estás tratando de cerrar esa brecha, pero es una calle solo para peatones y estás montando en bicicleta. Eso no está permitido. Así que quiero enfatizar realmente eso, cuanto mejor tipado sea tu sistema, mejor te ayudará tu tooling a usarlo. Los sistemas bien tipados pueden entenderse mejor.

En el pasado, ¿alguien recuerda cómo se escribían los componentes de clase en React? Eso fue importante por un tiempo. Muchos de nosotros. Así es como solíamos escribir las cosas. Esto es mucho code. Las clases también son realmente difíciles de tipar estáticamente porque muchas veces los métodos distintos del constructor pueden modificar tu estado y luego tienes este caso extraño donde otros métodos no lo saben. Es una pesadilla. Incluso el code, es, ¡oh, Dios mío, mira esto! Pero ahora tenemos componentes de función que son mucho más fáciles de tipar estáticamente. Hay una razón por la que solid.js no ha vuelto a los componentes de clase. Y una vez que comienzas a escribir cosas en TypeScript, obtienes esta hermosa cosa genérica. Te das cuenta, oh, Dios mío, TypeScript es realmente poderoso. Hay muchas cosas geniales que puedes hacer en el sistema de tipos. Puedes hacer genéricos que hacen referencia a otros genéricos o parámetros de tipo específicos. Puedes tener tipos mapeados que mapean de un tipo a otro. Puedes tener lógica condicional en el sistema de tipos Turing completo. Puedes tener inferencia extrema en tu lógica. Puedes implementar aritmética binaria en el sistema de tipos. ¡Puedes usar TypeScript para todo! Por favor, no lo hagas.

No sigas ese camino. Entiendo que ayer se mencionó el ciclo de hype de Gartner. Me gusta referirme al ciclo de tipos de TypeScript. Cada desarrollador que profundiza en TypeScript pasa por esto. Pasas por este pico de tipos inflados donde te das cuenta, oh, Dios mío, el sistema de tipos tiene lógica, puedo hacer de todo en él. Y luego abusas de eso y tus compañeros de equipo no tienen idea de qué diablos hace tu code. Entonces te desilusionas y te das cuenta de que no tienes idea de qué diablos hace tu code en el sistema de tipos. Así que dejas de hacer eso, con suerte.

Y luego, una vez que descubres la meseta de la productividad de tipos, cuando estás usando TypeScript de la manera en que se supone que debe usarse, y no abusándolo, es cuando eres más eficiente. Ese es un buen lugar para estar. Esto nos lleva al segundo de los cuatro casos, lo que no son los tipos, o lo que no es TypeScript en este caso. TypeScript no cura tu code enredado. TypeScript no arregla la arquitectura de tu aplicación. Si estás escribiendo basura incomprensible e ilegible, TypeScript solo puede ser un parche encima de eso. Si tienes ideas complejas, es probable que los tipos que describen esas ideas también sean complejos. Por lo tanto, es bueno preferir un código más simple que resulte en tipos más simples. ¡Consejo profesional! Vamos a ser serios ahora. Además, TypeScript no existe en tiempo de ejecución. TypeScript no es un ayudante en tiempo de ejecución. Los tipos no existen. Cuando se transpilan de TypeScript a JavaScript, las anotaciones de tipo de tu code simplemente se pierden. Algo como esto no funciona porque la interfaz some shape no existe en tiempo de ejecución. El JavaScript compilado simplemente no lo tiene, por lo que estás haciendo referencia a algo que no existe. No hagas eso. No hay tipos para ti. Quiero mencionar que en realidad hay una propuesta para agregar, entre comillas, tipos a JavaScript, pero es solo una nueva sintaxis para ellos. Es un espacio para poner comentarios que describen los tipos. Aunque esta es una propuesta muy emocionante, son solo comentarios. En realidad, no captura todo lo que es TypeScript, por lo que durante un tiempo todavía necesitarías TypeScript mientras iteran en ello, y está a años de distancia de las primeras pruebas.

Años y años. Resulta que agregar tipos a JavaScript es una propuesta algo controvertida, por lo que estará bloqueada en el comité durante mucho tiempo. Bueno, la razón por la que estoy realmente emocionado de hablarles sobre no usar tipos para ciertas cosas es porque los tipos no son la fuente raíz de todo. A menudo, en tu código, es mejor que tus tipos sean solo una descripción o un subproducto de tus valores. Escribes tu código y luego los tipos describen cómo se supone que debe ser ese código. Por lo tanto, no hay tipos en tiempo de ejecución, en su lugar, me sumergiré en la filosofía de los tipos aquí. ¿Cómo pasamos de un código muy bien descrito o valores muy claros a tipos realmente buenos, claros y bien descritos? En otras palabras, ¿cómo informamos a nuestros tipos de manera adecuada?

Lo primero que quiero mostrar son las bibliotecas de validación de esquemas, parte tres de cuatro. Bibliotecas de validación de esquemas bien definidas, por curiosidad, ¿quién aquí ha usado una como YUP, Zod o ArcType? Todas son excelentes opciones. Muchos, pero no todos en la sala. Hablemos de esto. En el pasado, teníamos esta antigua cosa en React llamada PropTypes, solía estar integrada en React y luego se separó. Esa fue una forma muy temprana de describir un esquema para validar y describir las props, las cosas que se pasaban a tus componentes. Lo cual es genial. Era bastante sencillo, como, este código es bastante legible. Es comprensible, entiendo lo que hace, pero no estaba completamente completo en cuanto a características de TypeScript, no se mapeaba a todas las características que uno podría desear en el sistema de tipos y, como resultado, la inferencia de TypeScript nunca se desarrolló completamente. Terminaste con muchas empresas que simplemente escribían todo dos veces. No nos gusta eso.

En su lugar, ahora tenemos, muchas veces, una nueva ronda de bibliotecas de validación de esquemas como la muy popular Zod. Esto se parece bastante al código anterior, pero lo interesante es que tenemos un esquema separado, un esquema de caja, y luego un ayudante incorporado de Zod llamado infer que toma el tipo del esquema de la caja y devuelve una interfaz o un tipo. Además de ser de uso sencillo y tener una sintaxis comprensible, también obtenemos paridad con TypeScript e inferencia de TypeScript. Así que eso es muy bueno. Ahora, no estoy diciendo que debas usar esquemas de Zod para todos los tipos de props de tus componentes. Si no estás validando tus props, no hay necesidad de eso. Pero si estás usando datos compartidos, utilizables y con formas validadas, esto es bastante bueno. Este es solo un ejemplo de cómo podría verse Zod en una aplicación más compleja. Zod admite uniones, que son tipos que representan valores que pueden ser uno o más posibles cosas, representa objetos, opcionales, todo tipo de cosas geniales. Un ejemplo de cómo podrías usarlo sería si tienes algunos datos desconocidos y quieres renderizarlos en un componente, bueno, podrías intentar analizarlos o analizarlos de forma segura con Zod y, si eso tiene éxito, renderizas el componente de la caja, o si no, renderizas algún error. Observa cómo no estoy haciendo mucho en TypeScript aquí. Estoy describiendo el Z.infer, estoy describiendo cuáles son las props, pero mis valores están describiendo la lógica, el flujo, el si no se analiza correctamente, entonces haz esto, de los valores vienen los tipos.

Y lo que también es muy interesante es que una vez que tienes estos esquemas reutilizables compartidos, puedes compartirlos entre el cliente y el servidor. Puedes tener el esquema en el paquete en el cliente que describe el tipo que enviarías en una solicitud de red, y luego también puedes tener el esquema utilizado en tu código en el servidor para validar que la solicitud de red se haya enviado correctamente. Eso significa que tienes una mejor seguridad de tipos, autocompletado y una mejor seguridad porque no sé cuántos de ustedes han tenido que validar manualmente que los parámetros de la solicitud sean válidos debido a un informe de hacker one, sobre un error 500, pero es una pesadilla, esta es una forma mucho mejor. Y al hacerlo, obtienes este tipo de belleza simétrica entre tu cliente y servidor donde tienes el esquema compartido que ayuda a ambos.

Entonces, en realidad hay varias formas diferentes de hacer lo que acabo de describir. La más cercana a lo que acabas de ver y que realmente recomiendo probar primero se llama TRPC. ¿Qué es seguro de tipos? ¿Qué significa RPC? ¡Gracias! ¡No escuché nada! En tu servidor, puedes definir tu esquema Zod y luego una cosa de consulta, si alguien te da opciones con una entrada, devuelves una cadena. Observa la constante 'as' allí, eso le dice a TypeScript que use ese tipo de cadena literal que verás en la siguiente diapositiva. Una vez que tienes eso en tu servidor, también puedes vincularlo con el cliente. Aquí hay un poco de código esqueleto, pero observa las últimas líneas a la derecha, 'await TRPC.greeting.query, name Attila', y el tipo de esa variable es 'HiAttila', quien, por cierto, era la foto que viste antes del chico con cara seria.

Otro enfoque interesante es GraphQL, que hoy en día es un poco más antiguo pero aún es bueno en casos de uso grandes. Hay diferentes formas de hacerlo. Una sería tener un archivo GQL o GraphQL que describa la sintaxis de GraphQL para un tipo, y luego algunas consultas en algún lugar, tal vez en un archivo de consulta. Creo que usé la extensión incorrecta en esta diapositiva. Puedes generar automáticamente tipos a partir de esos, a partir de tu esquema y tus consultas. Es realmente útil. El último de los tres es Open API, también conocido como Swagger. Aún no he determinado qué término se usa en qué contexto, pero puedes definir un archivo de esquema, digamos en YAML, y generar automáticamente tu código a partir de ese archivo de esquema. Este es un ejemplo pequeño. He visto archivos de esquema muy grandes y complejos, de una buena manera, con muchas características, generando SDK a partir de archivos de esquema. Alternativamente, puedes hacerlo al revés. Puedes usar código bien tipado para ser analizado estáticamente por Codegen y crear tu archivo de esquema directamente a partir de tu código. Desde tu servidor, por ejemplo, lo que significa que puedes generar SDK en diferentes lenguajes desde tu servidor. ¿Qué tan ridículo es esto? Comenzamos con un servidor TypeScript y ahora estamos generando automáticamente SDK en Python y Rust basados en eso. ¿Quién aquí escribe el SDK manualmente en una empresa que tiene múltiples lenguajes de SDK? Oh, cuatro de nuestras manos. Esperaba que fueran más. Claramente, todos ustedes están usando Open API. Esto es genial. Cuanto más tipificado sea tu sistema, mejor puede ayudarlo tu herramienta. Cuanto más tipificado sea tu sistema, mejor puede analizarlo tu herramienta.

Lo que los tipos pueden informar una vez que están bien tipados y bien descritos es nuestra última sección, y estoy muy emocionado por esta porque voy a hablar sobre en lo que trabajo día a día, ¡el linting con comprobación de tipos!

¿Quién aquí utiliza el linting con comprobación de tipos o con conciencia de tipos? ¡Wow! En realidad, un buen número. Gracias. Eso es increíble.

En primer lugar, probablemente deberías hacer lint a tu código TypeScript. No puedo decirlo con certeza, tal vez no eres una persona amante del lint, pero si los tipos están justificados en tu escala de aplicación, probablemente el linting también lo esté. Hay tres formas de análisis estático. El linting no significa comprobación de tipos. Hay formateadores, como prettier, que solo formatean tu código, no cambian la lógica. Eso significa que son de una manera buena, tontos, muy rápidos. Luego están los comprobadores de tipos que son muy poderosos pero más lentos, también conocidos como TypeScript. Y luego están los linters, como ESlint.

Ahora bien, los linters son geniales. Como ejemplo, pueden enseñarte nueva sintaxis. Hay una regla incorporada en ESlint, operadores de asignación lógica, que analizaría este código y diría, dato curioso, hay una nueva característica de JavaScript que puede escribir un código ligeramente más limpio para ti. Mira eso. Qué bonito. Hemos aprendido algo. Pareces inteligente. También pueden enseñar cosas específicas del lenguaje, del framework o de la biblioteca. ESlint con TypeScript te informaría, espera un segundo, ese nombre, hola, Daria, en realidad hay una función as-const que puedes usar para hacer lo mismo. Increíble. Pero eso solo se limita a la sintaxis en bruto. Y una vez que tenemos tipos, una vez que tenemos una conciencia no solo del archivo que estamos viendo, sino de todo el proyecto, podemos escribir reglas de lint mucho más poderosas. Podemos crear esta casi nueva clasificación de reglas de lint, como reglas de lint con conciencia de tipos o comprobación de tipos que aprovechan el poder de TypeScript.

Por ejemplo, podrías analizar este código y, debido a que tienes un sistema de tipos detrás de ti, podrías decir que sé a ciencia cierta que console.log debe devolver void, nada, no se debe usar, lo que significa que la regla await-venable de TypeScript ESlint podría decirte que esperaste un valor no promesa o, según la especificación, un valor no venable, algo sin un ven, eso es innecesario, eso solo desperdicia un tick en la ejecución de tu programa, así que podríamos sugerirte que lo elimines.

Ahora, ese ejemplo no es muy emocionante. Me doy cuenta de que ninguno de ustedes ha escrito await console.log, así que veamos algo más emocionante, algo de código de React que no te daré suficiente tiempo para leer, pero te diré que esto tiene un onclick que es una función, y en algún lugar dentro hay un controlador que se supone que establece un estado de ejecución en verdadero, esperamos onclick. Después de eso, establecemos running en falso. Con la misma regla de lint, podríamos decir espera un segundo, onclick devuelve void, no una promesa, por lo que la regla de lint nos diría que para este caso no creo que necesites hacer eso. Así que podríamos eliminar el onclick, o podríamos cambiar el onclick para que devuelva una promesa de tipo void.

Si nuestro code debe devolver una promesa, genial, eso funciona, pero ¿qué pasa si en realidad nunca usamos ese comportamiento asíncrono? ¿Y si el await se suponía que debía eliminarse, porque entonces si el await se suponía que debía eliminarse, podríamos ver que tenemos dos equivalentes de establecimiento de estados de React, esos se ejecutan de forma sincrónica, por lo que podemos eliminarlos. Dado que podemos eliminarlos, toda la función onclick y disable es innecesaria, así que podemos eliminar eso, lo que significa que el botón disabled es igual a running, el botón disabled es igual a false, lo que significa que podemos simplemente decir botón, no necesitamos disabled, ¡lo que significa que hemos eliminado un tercio de nuestro code con el linting! ¡Sí! ¡Woo! ¡Hell, yeah! ¡Gracias por el linting! Increíble. Recomiendo encarecidamente, mostraré recursos y referencias después de esto, utilizar el linting con comprobación de tipos para un conjunto de reglas de linting más informado y poderoso. Es un buen momento. Así que casi se me acaba el tiempo, solo recapitularé, iré rápido, estas son diapositivas con capacidad de fotos si lo desean. En primer lugar, ¿qué son los tipos? Los tipos son el pegamento de la información, ayudan a definir los límites del sistema, componente o área. Son geniales. TypeScript es un ciclo de tipos, por favor, trata de controlarte cuando recién estés comenzando y aprendiendo todas las cosas avanzadas. TypeScript no es algo que se ejecute, solo existe durante el desarrollo. Valores con tipos. El área Zen. Los esquemas bien definidos son útiles. Los tipos pueden informar a las herramientas, pero recomiendo probar el linting de tipos al menos. Si quieres empezar, todos los frameworks utilizados en los autores de frameworks y las dos primeras filas admiten TypeScript de forma predeterminada. Tenemos una excelente documentación y ESLint acaba de lanzar una versión beta de tipos en ESLint V8 que tiene muchas características excelentes, es compatible con ESLint V9, lo cual sé que a todos les molesta que aún no tengamos, lo siento, y tiene una nueva forma de configurar el linting de tipos que es un 10 a 20 por ciento más rápido, significativamente más fácil de configurar y con más funciones completas. Eso es todo lo que tengo. Muchas gracias a todos.

La pregunta más popular que ha surgido ha sido votada por muchas personas. Estoy seguro de que te la han hecho antes. ¿Tienes alguna opinión? Tipos versus interfaces. Tipos versus interfaces. ¡Oh, Dios mío, qué pregunta! ¿No fuiste tú, Attila? La mayoría de las veces no importa si usas tipos o interfaces, los dos son casi equivalentes en TypeScript. Ambos son cosas que pueden definir la forma de un objeto. Personalmente, recomiendo usar la regla de ESLint de TypeScript que consiste en definiciones de tipos que te permite elegir uno u otro. Personalmente, prefiero interfaces siempre que sea posible porque eso es semánticamente lo que estás tratando de transmitir. El tipo es más bien una copia y pega coincidental en términos de la semántica de TypeScript. Pero si eres del tipo de persona que piensa `solo uso tipo para todo`, genial para ti. Eso también está bien. Hay algunas cosas que solo se pueden hacer con interfaces y algunas cosas que solo se pueden hacer con tipos, lo cual es realmente molesto. ¿Debería haber una única cosa unificada? Es simplemente cómo evolucionó el lenguaje con el tiempo. No podemos cambiarlo.

Digo que no podemos cambiarlo, pero mi siguiente pregunta es si tienes alguna idea sobre el futuro, alguna idea de lo que podría venir en TypeScript 6. Sabes, de vez en cuando tengo una conversación con alguien que parece pensar que estoy en el equipo deTypeScript. Así que solo para estar seguro, no estoy en el equipo de TypeScript. He contribuido en el pasado como una persona externa, pero ha pasado tiempo. TypeScript 6.0 va a tener cosas increíbles. Pero incluso antes de eso, TypeScript 5.5 está a punto de ser estable. Tienes la versión candidata y beta. Y, oh Dios mío, 5.5 tiene estas características increíbles donde los predicados de tipo se pueden inferir a partir de los cuerpos de las funciones. Si no sabes qué es eso, es genial, solo ve a leer las notas de la versión. Son fantásticas. Si sabes qué es eso, sabes lo increíble que es. ¿Hay algo que te gustaría ver en TypeScript 6.0 o 5.6 o lo que sea? Hay una nueva API que recientemente se ha puesto disponible llamada 'is assignable to'. Eso va a facilitar mucho la escritura de reglas de linting con tipos realmente poderosas, lo cual me emociona mucho. También están depreciando gradualmente un montón de sintaxis antigua, lo cual también es muy emocionante. Eso es genial, sí. Sí, bueno.

Me gustan las deprecaciones lentas. Muy, muy, excesivamente lentas. Excesivamente lentas. Eso no es una pregunta. Siento que ya has cubierto un poco esto, pero si hay algo en lo que quieres profundizar más, ¿cuáles son las limitaciones de TypeScript? Es difícil responder a eso porque hay respuestas amplias que ya he dado y luego hay respuestas específicas. Así que responderé eso en persona si estás interesado.

De acuerdo. Hay una sesión de preguntas y respuestas en los stands allí atrás. Ven a hablar conmigo. Soy muy amigable. De acuerdo. En ese caso, ¿qué opinas de las clases en TypeScript y/o JavaScript? Estamos usando, supongo, la sintaxis de clase. ¿Es algo que recomiendas o no? TypeScript en sí no recomienda ni el enfoque de clase ni el enfoque funcional. No recomienda OOP versus FP versus cualquier otra cosa. TypeScript simplemente describe tu código. Las clases de la forma en que tradicionalmente se han interpretado los principios sólidos y la programación orientada a objetos realmente violan los principios sólidos y OOP. Así que diría que la forma en que estás escribiendo clases en Java probablemente es terrible. Solo prácticas relativamente más nuevas de Java me han hecho no infeliz. Hay muchos casos de uso válidos para las clases.

Por ejemplo, paquetes de datos pequeños que tienen un montón de ayudantes privados o la extensión de la clase de error. Así que hay usos para las clases. Personalmente, no las uso con frecuencia. Bastante justo. De acuerdo. ¿Hacia dónde nos dirigimos con esto? Boom. ¿Cuál es el futuro de ESLint en comparación con nuevas herramientas basadas en Rust como OXC? OXC, Biome, Dinolint? Muy emocionante. También me emocionó ver a otros ponentes mencionar este tema compartido de AST, como Evan ayer y Anthony. No hay un solo linter popular que pueda competir completamente con TypeScript ESLint en este momento. Tenemos linting tipado y ningún linter popular como Biome o OXC lo tiene. Sin embargo, eso no será así para siempre.

Recomendaría encarecidamente a cualquiera interesado en un linting significativamente más rápido o más fácil de configurar que eche un vistazo e incluso contribuya a proyectos como Biome y OXC. Están llenos de personas realmente agradables y estoy emocionado al respecto. También hay otro proyecto llamado TSSlint, que también está trabajando en este espacio. No debe confundirse con TSLint, que es la antigua cosa obsoleta que precedió a ESLint en TypeScript y que ayudé a eliminar. Genial. Pero sí, son muy buenos. Son muy rápidos. Mucho más fáciles de configurar. A costa de que aún son más nuevos, por lo que aún están alcanzando la paridad de funciones. Son más nuevos, por lo que también pueden avanzar más rápido, lo cual es realmente genial, supongo. Sí. Involúcrate. Si quieres verlo, involúcrate. Sí, seguro. Me encanta.

¿Tienes alguna regla favorita de ESLint? ¿Reglas favoritas de ESLint? ¡Oh Dios mío! Sí. No promesas flotantes, que dice que si creas una promesa, no la dejes simplemente flotando. Asegúrate de que algo como try-catch la capture o la almacene en una variable o la pase a una función. En realidad, estamos agregando muchas características a esa regla porque sé que a veces es difícil trabajar con ella. Esa venerable espera no promesas mal utilizadas. Hay un montón de reglas de ESLint de TypeScript que ayudan a hacer cumplir un buen uso de las promesas para evitar travesuras async-await, lo cual me gusta mucho. También hay una regla de deprecación, que es increíble, que te avisa si estás usando APIs obsoletas en TypeScript, lo cual es extrañamente útil en la empresa. Cualquier regla de deprecación, sí. Además... Avanza hacia las cosas modernas. Sí.

¿Tienes alguna buena recomendación de libro de TypeScript? ¿Alguna buena recomendación de libro de TypeScript? Sí. Obviamente el mío es genial.

Blah, blah, blah. Pero Effective TypeScript, segunda edición acaba de... Sí, la segunda edición acaba de salir de Dan Van Der Kam, quien escribió la característica de predicados de tipo en TypeScript 5.5. Es una excelente lectura. Me gusta como, entre otros usos, una continuación del aprendizaje de TypeScript. Realmente profundiza y explica muchas prácticas recomendadas y cosas que se deben evitar en todas partes, junto con la razón de ser de cada una. No puedo recomendar Effective TypeScript lo suficiente.

Si puedo agregar algo, leí el libro de recetas de TypeScript de Stephan Baumgartner. Sí, el libro de recetas de TypeScript. Y está lleno de ejemplos prácticos y problemas que puedes encontrar y resolver usando TypeScript. Realmente me gustó también. Sí. El libro de recetas es genial. Sí. Hablaste sobre los comentarios de tipo en JavaScript, pero ¿debería TypeScript estar disponible en tiempo de ejecución? Sí. ¿En tiempo de ejecución TypeScript? TypeScript nunca debe agregar tipos en tiempo de ejecución. Eso no es algo que debamos o podamos construir en un superset tipado de JavaScript. Se supone que se utiliza de la forma en que se utiliza TypeScript. Sin embargo, hay muchas bibliotecas que puedes usar para agregarlos, si eso se ajusta a tu caso de uso específico. Te animo a que eches un vistazo a ArcType. Es una biblioteca realmente genial de David Blass en Boston, donde me mudaré en agosto. ¡Woo! Y hace muchas travesuras de tipos realmente geniales. Genial.

OK. Will? Esto es otro, Will, TypeScript tiene soporte para cosas que tal vez no sepas. ¿Crees que TypeScript agregará soporte para la sintaxis de componentes y los tipos de representación? Aparentemente Flow lo tiene. Sí. De hecho, conectando con Flow, Flow tiene esta increíble sintaxis de componentes que facilita la declaración de componentes de función de React y similares. No lo obtendremos en TypeScript hasta que se implemente en JavaScript, porque TypeScript ya no agrega nuevas cosas en tiempo de ejecución, y eso se acerca a eso.

Es una sintaxis diferente a JavaScript, lo cual TypeScript teme hacer. No quieren un conflicto. Así que sí, si se implementa en JavaScript, lo cual dudo mucho que suceda en la próxima década, pero nunca se sabe, entonces lo haremos. Maravilloso.

Aparte de dar charlas en conferencias, ¿cómo evitas entrar en largas discusiones sobre teoría de tipos mientras discutes con colegas sobre TypeScript? Bueno, en primer lugar, renuncio a mi trabajo. ¡Así que no tengo colegas! ¡Sin colegas! Pero cuando los tenía... Perfecto. Hay un momento y un lugar para estas discusiones. Si estás teniendo una discusión larga sobre tipos, debería ser en un contexto y situación donde te sientas cómodo y ellos se sientan cómodos. Gritarse el uno al otro en una reunión de equipo o en una solicitud de extracción no es bueno. Para cuando algo llega a una solicitud de extracción, deberías tener una expectativa compartida de qué tipos usar. A veces simplemente no importa. Elige uno y sigue adelante. Ese es un tema esotérico para la mayoría de las personas. Establece límites de tiempo para la discusión. Establece límites de tiempo. Genial.

Tienes opiniones al respecto, creo. ¿Debería ESLint también ser responsable del formateo del código? Tuve una conversación muy buena con Anthony Foo, creo que hemos tenido la misma conversación tres veces. Desde el punto de vista de la implementación, ESLint y Prettier o los linters y formateadores son muy diferentes. Y ESLint y los linters no son buenos para el formateo. Estructuralmente no son buenos en eso. Sin embargo, es una molestia tener dos herramientas diferentes, por eso todos están tan emocionados con Biome, porque Biome mejora mucho esta experiencia. Entonces, fundamentalmente, no lo creo, pero reconozco por qué el proyecto de estilo de ESLint, que te permite usar ESLint como formateador, es muy agradable. Así que, eh. Tengo tiempo para una más. ¿ESLint TypeScript hace innecesario ejecutar TSC? Es una gran pregunta. No hace innecesario ejecutar TSC. Siempre olvido buscar si hay un complemento que muestre los diagnósticos de TypeScript, que son las salidas, las ondulaciones, pero no, no mostramos los errores de comprobación de tipos de TypeScript. Eso simplemente no es lo que hacemos. Eso es lo que hace TSC. Muy bien. Bueno, eso es todo el tiempo que tenemos para preguntas. Aplaudan una vez más a Josh. Muchas gracias. Gracias a todos. Gracias, Phil. Fue genial.