Porque hoy vamos a aprender TypeScript desde cero.
Pero si hay algo que merece la máxima felicidad, en realidad, es que hemos llegado a los 50.000 en YouTube.
50.000 en YouTube.
Ya se nos queda la mitad.
Bueno, perdonad, esta es la energía que tengo yo los viernes.
Pero que somos 50.000, que muchísimas gracias.
Que ya somos 50.000 en YouTube.
Que me llena de orgullo y satisfacción.
Bueno, 50.004.
Es que esto va en tiempo real, aquí actualizándose.
50.004.
Solo nos quedan ya 49.996.
Así que si conoces a 49.996 personas, le puedes indicar que no sé si es el mejor canal de YouTube.
Pero sí que el que necesita a 49.996 personas.
Así que se lo puedes compartir y recomendar con midu.tuve.
Pero antes de empezar con el curso de TypeScript, y ya que hemos celebrado un poquito los 50.000, que muchas gracias.
Me podéis ir diciendo por el chat cómo celebramos los 50.000.
No sé, yo he pensado en hacer un directo en YouTube.
Y hacer un clon de TikTok desde cero, en directo, en YouTube, hasta que nos salga.
Como si queremos estar...
Bueno, hasta que nos salga.
A ver, no vamos a hacer exactamente la misma aplicación.
Pero bueno, hasta que nos salga algo con cara y ojos.
Y no sé, estar ahí un rato hasta que nos salga.
Y ir haciendo, ir hablando y que vaya pasando la gente.
No sé, a ver qué os parece.
Me comentáis a ver qué os parece la idea.
Vale, que os leo, os leo.
Fran desde Argentina.
Colzarius dice que está pasando la plataforma en la que trabajan a TypeScript.
Por lo pronto estamos entretenidos.
Qué bueno.
Así te va a ir bien lo de hoy.
Esteban dice, grande.
Rey Katakamichi se puede y se debe.
Qué grande.
Miosiz, buenas.
Hola, Gen Caldas.
Soy Franz.
Se queda, se queda.
Se queda.
Jeff, Tutark, Esubert, Taddez.
¿Qué tranza?
¿Qué pasa?
Desde Tigre, Argentina.
Madre mía.
¿Cuál es la ventaja de aprender muchos lenguajes de programación?
Me encanta que ya venís con preguntas pero preparadas de casa y además casi filosóficas.
¿Cuál es la ventaja de aprender muchos lenguajes de programación?
Pues mira, yo creo que hay una ventaja bastante interesante de aprender muchos lenguajes de programación.
Y es que te da la oportunidad de conocer muchos paradigmas distintos.
Claro, si conoces muchos lenguajes de programación y siempre son el mismo, igual, no.
Pero aparte de hacerte más versátil y que puedas tener más oportunidades laborales, yo creo que la oportunidad de conocer diferentes paradigmas de programación, como por ejemplo uno funcional, otro más que sea procedural, aunque no es muy típico, pero bueno, procedural podría ser uno.
Otro orientado a objetos y tal. Esto lo que hace es expandir tu mente. Así que esa sería la gran ventaja.
Desde Sabadei tenemos también a gente, Luis Riego, Luis Guidev, Centic, Zabotec.
¿Tú usas TypeScript en el trabajo? Pues me la cajota. Muy buena pregunta.
Ahora mismo no utilizo TypeScript en el trabajo y por eso mi experiencia en TypeScript es más bien limitada.
Porque como mi día a día no lo utilizo, pues por eso justamente quería venir hoy aquí y aprender TypeScript con todos ustedes.
Y lo vamos a hacer con un curso de Microsoft oficial, desde cero, lo vamos a seguir paso a paso, además el curso es en castellano.
Y así aprendemos todos. Quien se quiera unir conmigo a aprender, yo lo voy a ir comentando a voz alta, las cosas que pienso, lo que voy haciendo y tal.
Así que si queréis aprovechar y aprender conmigo, pues mejor que mejor.
¿Luego harás un proyecto de Context? Pues puede ser.
¿Se va a grabar la sesión? Sí, todas las sesiones se graban.
Y ya intentaremos subirla en el canal secundario que tenemos.
Pelado nuevo, vida nueva. Felicidades, Lurrego, por tu título en el Bootcamp.
Muchas gracias a todos los que me felicitáis por los 50.000.
Muchísimas, muchísimas gracias.
Y bueno, pues nada. Es que veo que no para esto de escribir, ¿vale?
Luego, si no, ya volveremos a leer un poquito, ¿vale?
Un clon de YouTube y que todos los canales sean mi dudez.
Ostras, no es mala, ¿eh? Un clon de YouTube.
Vale, vale, me lo apunto. Un clon de YouTube.
Me gusta, me gusta.
Estábamos hablando también, si acabas de entrar, de que hemos llegado a los 50.000 suscriptores en YouTube.
Lo tengo aquí en tiempo real.
Bueno, 50.007, se ha unido alguno más.
¿Y qué podíamos hacer para los 50.000?
Y estaba pensando en hacer un directo en YouTube y hacer un clon de alguna aplicación.
Había pensado TikTok porque parece bastante interesante.
Pero bueno, ahora me estáis diciendo un clon de YouTube.
Me lo puedo pensar también, me lo puedo pensar también.
Pero me parece buena idea.
Un clon de YouTube con Next.js, dicen por aquí.
Madre mía, ¿cuál es el 50.000?
No sé quién será el 50.000, pero muchas gracias.
Ahora, el que sea el 50.000, muchas gracias a todos.
Muchas gracias a todos por las felicidades.
Os lo agradezco un montón.
Gracias por vuestro apoyo.
Hoy vamos a aprender TypeScript, ¿vale?
Hoy vamos a estar haciendo el curso oficial este de Microsoft para aprender TypeScript.
Bueno, aquí me dice un clon de Amazon, de Spotify.
Hola, Cami.
Hola, Marcos.
¿Cómo estáis?
Gracias por pasaros.
Vamos a empezar con el curso.
Vamos a empezar con el curso un poco.
Al menos vamos a estar un ratito con el curso este.
Este es el curso que quiero hacer, ¿vale?
Compilación de aplicaciones JavaScript con TypeScript.
Dice que son 6 horas y cuarto.
O sea, que hoy a lo mejor hacemos lo que nos llegue.
Nos dice que de requisitos previos HTML básico y JavaScript.
Saber, bueno, lo que ya sabéis y lo que habéis aprendido en el Bootcamp, seguro.
Y software que tenemos que tener, Git, Visual Studio Code, Node.js y TypeScript.
Vale, TypeScript no lo tengo, pero me imagino que en algún momento me dirá cómo instalarlo.
Así que lo instalaré sin problemas.
Aquí saqué de este tuit este curso que me pareció tan interesante.
¿Estás interesado en aprender TypeScript?
Y yo, yo, yo, yo, yo estoy interesado, yo estoy interesado.
Os lo voy a pasar por si en algún momento lo queréis hacer, ¿vale?
O lo queréis seguir conmigo o lo que sea.
Así que os paso el link.
Es totalmente gratis.
Lo podéis hacer cuando queráis, como queráis.
Es de Microsoft oficial.
Quiero pensar que está bien actualizado, ¿vale?
O sea, que está actualizado a algo reciente.
Porque yo sé que toqué TypeScript, pero hace mucho, mucho tiempo.
Y quiero pensar que esto está actualizado.
Porque se lo recomienda Microsoft hace poco, el otro día, 3 de abril.
Quiero pensar que está actualizado.
Así que este es el que vamos a seguir, ¿vale?
Por si lo queréis hacer y tal.
Bueno, por si lo queréis entrar y eso.
Vale, pues vamos a ello.
¿Os parece?
Compilación de aplicaciones de JavaScript con TypeScript.
Vamos a darle a continuar.
Bueno, a continuar que debe ser empezar, básicamente.
Información general.
Bueno, introducción a TypeScript.
Primero nos van a presentar el lenguaje de TypeScript.
¿Por qué se creó?
Eso es interesante.
¿Por qué se crean las cosas?
Si vais a aprender alguna vez algo, por ejemplo, React.
Yo cuando hice el curso de YouTube que tenemos de React, veréis que al principio explico por qué necesitar React.
Porque yo creo que es muy interesante saber por qué necesitas las cosas antes de aprenderlas.
Y además así entiendes las ventajas que te da y lo aprendes de una forma distinta.
Así que me parece muy bien esto que ha dicho.
Objetivos.
Entender por qué TypeScript es una mejora respecto a JavaScript.
Seleccionar un editor de TypeScript.
Instalar TypeScript.
Configurar un proyecto de TypeScript.
Vale.
Eso es lo que quiero.
Selección de un editor de TypeScript.
Vale.
Puedes escribir código de TypeScript en cualquier editor, pero nosotros vamos a usar Visual Studio Code.
¡Gracias, Colzarius, por suscribirte con Prime!
Ya van tres meses.
Vaya pedazo de crack.
Tres meses.
Muchas gracias.
Muchas gracias por apoyarme.
Sin ti y sin vosotros es que nada de esto sería posible.
Ni los 50.000 seguidores de YouTube, ni todo lo que hago en Twitch, ni nada.
Así que gracias por vuestro cariño.
Sitio de prueba.
Anteriormente.
¿Cómo que anteriormente?
Yo he dicho anteriormente escribí el código TypeScript siempre en el sitio de prueba.
Yo no he hecho nada de eso todavía.
Me imagino que la traducción es un poco de aquella manera.
Este es un lugar en el que puedes escribir, compartir y no sé qué.
Bueno, que aquí hay un playground y que podríamos hacer un poquito de TypeScript, me imagino.
Y ya está.
Muy bien.
No lo vamos a saltar.
Experimentar, experimentar.
Entorno de desarrollo integrado.
Esto sería con Visual Studio Code.
Ya tenemos Visual Studio Code instalado.
Entiendo que vosotros también.
Así que no vamos a perder el tiempo con esto.
¿Cómo que me he ido a la página tres?
¿Me he saltado algo?
Ah, vale.
Sí, es que me he saltado todo esto.
Perdón.
Perdón, perdón.
Bueno, a ver.
¿Y cómo ha sido eso?
¿No?
Le he dado a continuar.
Bueno, siguiente.
Me he saltado esta página.
Vale.
Información general de TypeScript.
Esta parece más interesante.
JavaScript es uno de los lenguajes de programación más usados del mundo y que se ha convertido
en el oficial de la web.
Me ha encantado eso.
Se ha convertido en el oficial de la web.
Es verdad, porque no siempre iba a ser el oficial.
Lo que pasa es que poco a poco, desde que lo creó Netscape, aunque JavaScript se usa para
crear aplicaciones multiplataformas, no está concebido para aplicaciones grandes que impliquen
millones de líneas de código.
Bueno, bueno.
Carece de algunas características, claro, como por ejemplo el tipado.
Ahí es donde está TypeScript que aborda las limitaciones de JavaScript sin poner en
peligro la propuesta de valor clave de JavaScript, que es ejecutar el código en cualquier sitio.
Ahí está.
Así que, ¿qué es TypeScript?
Importante.
¿Qué es TypeScript?
TypeScript es un lenguaje de código abierto desarrollado por Microsoft.
Parece mentira, ¿eh?
Microsoft la de cosas que tiene desarrolladas y ahora en el mundo de la web, ¿no?
Y que ahora tiene GitHub, NPM, es brutal.
Se trata de un supraconjunto de JavaScript.
Esto es súper importante, porque esto lo que quiere decir es que tu código de JavaScript
debería ser compatible al 100% con tu código en TypeScript, ¿sabes?
O sea, deberías ejecutar tu código de JavaScript en TypeScript sin ningún problema, sin añadir
ni una línea.
Debería ser totalmente compatible.
Lo que significa que puedes seguir aprovechando tus conocimientos actuales sobre JavaScript.
Sugerencias de escritura.
Claro, la característica principal de TypeScript es su sistema de tipos.
Esto es importante, porque en JavaScript el sistema de tipos es blando, o sea, es un
tipado débil y es un tipado dinámico.
Y con TypeScript justamente lo que vamos a tener es un tipado estático, porque vamos
a tener que decirle cuál es el tipo que tiene.
Y, hombre, puede ser dinámico aún así.
Bueno, vamos a ver, ¿ves?
Mediante la comprobación de tipos estáticos, TypeScript al principio del desarrollo detecta
problemas de código que JavaScript normalmente no puede detectar.
Claro, es que esto es lo realmente interesante.
O sea, esto es una cosa que me gusta mucho de TypeScript, porque tú al final puedes escribir
tu código de TypeScript sin necesidad de añadirle tipos y debería detectar si tienes
algún problema cuando intentas cambiar el código de, o sea, una variable a otro y ya
está.
A ver, os voy pasando el link, que por si alguien se lo ha perdido.
Vale.
¿Ves?
La escritura de tipos puede ser opcional.
Lo voy a hacer más grande y todo, ¿vale?
Puede ser opcional en TypeScript, ya que la inferencia de tipos, esto es lo más bonito
de TypeScript y esto sí que sería una cosa genial que se pudiese activar en JavaScript.
Y aquí os dejo lo que yo creo que ocurrirá en el futuro.
Igual me equivoco, ¿eh?
Pero creo que en algún momento tenemos esto, ¿vale?
En JavaScript, el useStrict, que esto lo que te dice al final, bueno, es así, que esto
al final lo que te dice es que tienes que utilizar la forma estricta de JavaScript, el
compilador en formato estricto, que tiene más, digamos, que tiene como más checks y
tal.
Pues no me extrañaría que en algún momento tengamos algo así, ¿eh?
UseTypes o lo que sea.
Y que entonces tengas exactamente esta inferencia de tipos que tiene TypeScript, pero la tengas
en JavaScript.
Yo no lo descarto.
Yo ahí os dejo la idea.
Ya, ya veremos si lo pego y si no, ya me diréis.
Vale.
Pruébalo.
Venga, vamos al sitio de prueba que dice que copiemos y peguemos este código que me
imagino que nos va a enseñar el tema este de la inferencia de tipos.
Fíjate que cuando compila, porque al final TypeScript lo que hace es compilar el código
a JavaScript.
Y aquí estaría el código en JavaScript.
Y ha añadido justamente arriba el useStrict.
¿Vale?
Aquí ya me está diciendo aquí, se me queja de algo, ¿no?
Que dice que el parámetro x tiene un tipo como si fuese any.
Bueno, esto más que un error, sería como un warning.
Si no soportas el any, puede ser que te lo diga.
Pero entiendo que la gracia aquí sería que si le cambian los tipos en algún momento,
aparece el mismo código.
Claro, el código de la izquierda y el de la derecha es exactamente el mismo.
O sea, no está haciendo ningún tipo de cambio.
Y aquí, claro, si le pasamos 3 y 6, no sé si al final, si hiciésemos, por ejemplo,
z, x más y un string.
Bueno, pues yo veo aquí que esto se le ha quedado bien.
No.
Z y console.log.
Pensaba que ahí no le iba a gustar.
Pero ya veo que sí.
A ver, más z.
A ver.
Pues no.
Pensaba que a lo mejor se quejaría, ¿sabes?
Con la inferencia de datos y tal.
Pero ya veo que no.
Selecciona ejecutar.
Ah, vale, que hay que darle a ejecutar.
No me digas eso.
Que hay que darle a ejecutar.
Run.
Vale.
No, esto es para el log.
Vale.
Selecciona apañar registros y observa que el valor 9 se ha registrado en la consola.
JavaScript ha asignado el tipo number, los parámetros x y la función ha devuelto el número.
Reemplace el 3 por 3.
Vale.
Vamos a reemplazar.
Vamos a quitar esto que había hecho yo aquí.
Y vamos a reemplazar el 3 por 3.
Vale.
Muy bien.
Y ahora le damos a run otra vez.
Bueno, pero esto lo que veo ahora es que ha petado, ¿no?
O sea, ha petado.
Que básicamente me está haciendo esto mal.
JavaScript ahora asigna el tipo a string.
Vale, perfecto.
En el papel de JavaScript se observa las líneas rojas.
Esto es lo de Lenny que hemos visto antes, ¿no?
Que estaba asignándole.
Claro, como no estamos diciendo nada, pues aquí el parámetro dice que el tipo que tiene es que puede ser cualquier tipo.
Entonces, pues no sabe exactamente qué tipo es.
Perfecto.
Voy a cerrar esto.
En el panel de las luces rojas, TypeScript ha asignado implícitamente un tipo any.
La verdad es que, hombre, me hubiera gustado que fuese un poco más inteligente, ¿no?
Si le pongo aquí un 3, yo esperaría que implícitamente dijese que esto sí va a ser un number.
Actualice el código de TypeScript para especificar un tipo de cada parámetro.
Vale.
Pues le vamos a decir que la x, para decirle qué tipo es, se le ponen dos puntos y le vamos a decir que es un number.
Y la y, dos puntos, le decimos que es otro number.
¿Vale?
Y esto lo podríamos ejecutar y ahora sí que tenemos aquí el 9.
¿Vale?
Así que ahora debe funcionar mejor.
Ok.
Ahora sí, si yo le pongo aquí el 3, entiendo como el string.
Veis en el error, ahora me dice el argumento del tipo string no es asignable al parámetro de tipo number.
Bueno, esto está bastante claro y de hecho aquí nos lo dice.
Esto está muy bien.
Vale.
Actualizar el código y el error, reemplazar el tree por un número.
Vale.
Esto ya lo hemos hecho.
Justo lo que nos dice ya lo hemos hecho.
Otras características de código de TypeScript, que estas son las realmente interesantes.
Interfaces, espacios de nombre, genéricos, clases abstractas, modificadores.
Supongo que las veremos todas, de semana tras semana.
Decoradores, sobrecarga de funciones, tipos de utilidad y read only, para evitar volver a asignar una variable o montar algo.
Compatibilidad de TypeScript con JavaScript.
TypeScript es un super conjunto estricto de Xmascript 2015.
O sea, esto es algo a tener en cuenta.
O sea, es de Xmascript 2015, no de cualquier versión de JavaScript, ni de las últimas.
Claro, si tu JavaScript está utilizando Babel, que lo tengas en cuenta.
Esto significa que todo el código de JavaScript es también código TypeScript,
por lo que un programa escrito en TypeScript puede consumir JavaScript sin problemas.
Los exploradores se entienden JavaScript y por eso hay que compilarlo.
Si no, tú no puedes ejecutar o evaluar TypeScript en el navegador.
No hay ninguna forma de hacer eso.
Por desgracia.
Si eso se pudiese hacer, ya os digo yo que TypeScript sería más usado que lo que es ahora.
Si ya se usa bastante.
O sea, que imagínate.
¿Ya sabes usar TypeScript o estás aprendiendo ahora?
A ver, sé usarlo un poco.
Pero ahora aquí lo estoy haciendo desde cero y lo estoy haciendo desde cero para que lo aprendamos y tal.
¿Compilar o transpilar?
Mira, qué buena pregunta.
Compilar o transpilar.
A ver, realmente, realmente es compilar.
¿Ok?
O sea, es compilar.
En el sentido de que, bueno, no es una opinión mía, ¿eh?
Sino que si miramos TypeScript, vamos a buscar TypeScript, ¿vale?
Vamos a buscar aquí TypeScript y vamos a buscar su propia definición.
No sé si pondrá por aquí.
¿Ves?
TypeScript Code es transformado en JavaScript utilizando el compilador de TypeScript, ¿vale?
Compilador de TypeScript.
O sea, lo dice la propia documentación.
No es que yo diga compilar o transpilar.
Entonces, si lo entendemos como transpilar, pues entenderlo como transpilar.
Si lo entendéis como compilar, como compilar.
¿Qué pasa?
Que compilar, antiguamente, quería decir más, pasar el código más, digamos, de alto nivel, como puede ser C++ o lo que sea, a lenguaje máquina.
Y a lo mejor la definición se quedó en eso.
Pero al final compilar lo que quiere decir es transformar el código.
O sea, que pueda ser capaz de adaptar un código y convertirlo a otra cosa.
Si le queréis decir transpilar, pues transpilar, que al final es lo mismo.
Pero ya os digo que la definición que hace Babel, Babel mismo, ¿eh?
Si vais a Babel también habla de compilador, no de transpilador, ¿vale?
Compilador, compiler, es un compilador.
Así que yo creo que cualquiera de las dos la podéis utilizar sin problemas.
Como veáis, ¿eh?
Es mucha gente, mucha gente dice que transpilar sería más bien cuando es, es que al final debería ser lo mismo, pero bueno.
Cuando es de un lenguaje, del mismo lenguaje al, o sea, como lo que hace Babel, ¿no?
En lugar de ser lenguaje máquina.
Bueno, no voy a entrar en esos debates estériles.
Estériles.
Vale.
Selección de un editor.
Bueno, ya hemos dicho que es Visual Studio Code.
Si no lo tenéis, pues instaladlo.
Vamos a lo siguiente.
Instalación del compilador.
Esto sí que es importante.
El editor de código podría tener compatibilidad, que como es Visual Studio Code, puede instalar TypeScript globalmente o localmente.
En este ejercicio instalará TypeScript globalmente, lo cual a mí ya no me gusta.
Pero bueno.
¿Por qué no me gusta?
Porque realmente, pues cada proyecto es un mundo.
¿Y por qué tengo que tenerlo de forma global?
Pero bueno.
Lo vamos a dejar.
Vamos a seguir sus pasos.
Para instalar de forma global, ya tenéis que tener Node y tenéis que tener NPM.
Pero no vamos a entrar en ello, porque entiendo que ya lo tendréis.
Así que, vale.
Lo instalamos de forma global, así con NPM install menos G TypeScript.
Y escriba TSC para confirmar que TypeScript está instalado.
Venga.
Pues sí.
Está instalado.
Vamos a ver cuál es la versión.
4.2.4.
Vamos a la siguiente.
Vamos a compilar un archivo.
TypeScript es un supraconjunto.
Sí, cuántas veces me lo va a recordar que es un supraconjunto.
Que ya sé que es un supraconjunto.
Bueno, me lo dice porque vamos a escribir, entiendo primero, JavaScript.
Esto significa que todo el código de JavaScript es también código TypeScript.
Pero no todo el código TypeScript es JavaScript.
Y es porque TypeScript agrega sintaxis nueva a JavaScript.
Esto es importante.
Una vez que escribáis TypeScript y hagáis algo que solo hace TypeScript,
hay que tener cuidado porque necesitaréis ya el transpilador o compilador.
Aquí dice, por esta razón, TypeScript requiere un paso de compilación.
Y pone transpilador.
Fíjate.
O sea, compilación, pero habla luego transpilador.
Justamente para que la gente que no se queje.
Para transformarlo en JavaScript para que la aplicación funcione.
Vale.
Dice, TypeScript utiliza el compilador de TypeScript o un transpilador compatible con TypeScript.
Como Babel, SWC o Sucrase.
Sucrase.
Pues ahora también está Sbuild.
Sbuild también compila TypeScript.
Sí, sí, no.
Iba a decir, si no me equivoco, pero estoy bastante seguro.
Bastante seguro.
Uy, mira, por cierto, fíjate, está mi vídeo aquí.
He puesto Sbuild y lo primero que sale aquí en mi vídeo.
Madre mía, qué bonito.
Compilación de un archivo de TypeScript.
Venga, para ejecutar el compilador de TypeScript en el símbolo sistema usa el comando TSC.
Vale, ya he visto el TSC.
Cuando ejecute TSC sin parámetros, compilará todos los archivos TS de la carpeta actual.
Vale.
Y generas un archivo JavaScript.
También puedes compilar, no sé qué, no sé cuánto.
Por ejemplo, para compilar un archivo TypeScript.
O sea, vamos a empezar aquí aprendiendo TypeScript.
Aprendiendo, que se me ha olvidado esto.
TypeScript.
Venga.
Yo entro aquí.
Vamos a ver si funciona.
Cd aprendiendo.
Ahora sí.
Aquí.
Vamos a sacar aquí nuestro first.tss.
Y ahora aquí vamos a decirle que tenemos una función suma con A, B.
Vale.
A más B.
Mirad, fíjate que es genial el editor este.
Claro, Visual Studio Code utiliza TypeScript.
Y ya entonces tienes los errores aquí directamente que te los dice.
Si yo ahora ejecuto TSC.
Vale, pues ya no he ejecutado absolutamente nada.
Pensaba que decía que si ejecutabas TSC, es opcional escribir la extensión del archivo.
Vale.
Genera un archivo.
Si no hay ningún error, puedes compilar un archivo.
Por ejemplo, para compilar un archivo denominado tal.
Ah, vale.
O sea que.
Pero decía que cuando ejecute TSC sin parámetros adicionales, compilará todos los archivos
TS en la carpeta actual y generará un archivo JS para cada uno.
Pero eso es mentira.
Porque justamente es lo que acabo de ejecutar y lo que me está diciendo es, oye, que no
me estás indicando nada.
O sea que nos están engañando ya.
Ya este curso nos está engañando.
He tenido que poner TSC y el nombre del fichero y ahora sí tengo aquí mi archivo JS, que
al final ahora mismo es exactamente el mismo.
Pero bueno, vamos, vamos para adelante.
Las opciones del compilador te permiten controlar cómo se genera el código JavaScript a partir
del código de TypeScript.
Hay diferentes formas de hacerlo.
Encontrarás una lista completa de opciones en la documentación de las interfaces de línea.
Esto básicamente es lo que hemos, oye, pero ves esto porque a mí no me funciona.
Yo cuando he ejecutado TSC no me ha hecho, cuando hago TSC me aparecen todas las opciones.
Como diciéndome, oye, necesito algo para funcionar.
En cambio aquí dicen, ejecutar el compilador.
Entiendo que hay que tener el archivo TSC config.json para que esto funcione sin parámetros.
Yo creo.
Si no, hay que hacer este.
Vale, esto sería para una carpeta entera.
Esto referenciando el proyecto a partir del TSC config para emitir también las declaraciones.
Esto lo veremos más adelante, que es este D.ts.
O sea que por ahora nos podemos olvidar.
Vale, aquí están todas las opciones, pero bueno, no las vamos a mirar por ahora porque
entiendo que el curso nos irá llevando una a una sin necesidad de preocuparnos.
Por ahora, aquí ya nos dice algunas más comunes.
No implicit any, no emit on error y target.
La opción no implicit any indica al compilador que genere errores en expresiones y declaraciones
con un tipo any.
O sea, que si yo por ejemplo, ahora aquí, en esta que habíamos puesto, porque yo aquí
en el editor, ves, este dice parámetro a y este lo que me está diciendo es que tiene
el tipo any.
Si yo ejecuto este TSC, como lo hemos puesto aquí, TSC first, y le digo no implicit any,
a ver qué dice esto.
¿Ves?
Me peta.
Me dice no, no, no, es que claro, es parámetro a implícitamente tiene el tipo any, porque
no me has dicho el tipo.
Esto sería una forma de ser bastante más estricto.
Vale.
La opción target sería para decirle cuál es la versión de ECMAScript que vas a soportar.
En este ejemplo se compila un archivo de Javascript compatible con el Maccript 6.
Vale.
Bueno.
Pone que más adelante vamos a ver más opciones.
Configuración de un proyecto TypeScript.
Venga.
Configuración de un proyecto TypeScript envíos a Studio Code.
Bueno, Studio ya ha abierto esto.
Crear un proyecto, nada, ya he creado el proyecto, ya tengo esto.
A mí me dice, pues mira, justamente me dice que cree un archivo aquí que se llame
module01.
Pues eso vamos a hacer.
Venga.
Voy a quitar el que tenía, voy a dejar esto vacío, y así seguimos.
No, ya el curso.
Module01.
Y presiona entrar.
Generación de un archivo tsconfig.
¿Ves?
Esto es lo que me tenía que haber dicho antes y quería que funcionase lo de ejecutar.
Puedes usar la opción init del compilador de TypeScript para generar un archivo tsconfig
con acciones preterminadas.
Vale.
Me parece bien.
Hagamos eso.
Vamos a la terminal y vamos a hacer el tsc-init que nos va a crear el archivo tsconfig.json de
nuestro proyecto.
Vamos a ver qué nos ha dejado por aquí.
Ostras, nos ha dejado un montón de cosas.
A ver qué tal.
Compiler options.
Esto sería para la compilación incremental.
El target por ahora es 5.
Vamos a poner es 2015.
Porque es 5 sería más para Internet Explorer 11.
Y tampoco me parece tan...
O sea, no vamos a hacer un código que sea para eso.
Y seguro que va un poquito más rápido.
¿Vale?
Porque cuando tú compilas para lo que serían navegadores más antiguos, la compilación tiene
que hacer más cambios.
Así que cuanto más, peor.
Así que vamos a hacer eso.
Module Common GS.
Esto es el tipo de módulos que utiliza.
El Common GS sería como el de Node, que sería con los Requires.
El S2015 o S2020 o Snex, me imagino que estos, serían con el Import y el Export.
¿Vale?
Por lo demás, veo que está todo comentado.
Vamos a mirar solo los que no están comentados.
Skip Lip Check, que supongo que no hace el chequeo de los archivos de declaración.
Esto lo veremos más adelante.
Y Force Consistent...
¡Oh!
Esto es muy bueno.
Esto es una opción muy buena.
Esto, básicamente, es para tener siempre referidos los archivos de la misma forma.
En lugar de hacer, por ejemplo, módulo 01, módulo 01.
Claro, esto puede dar problemas.
De hecho, en el Bootcamp tuvimos problemas sobre esto, por si te interesa.
Bueno, lo importante es que ya tenemos nuestro tsconfig.
Vamos a continuar con esto, ¿vale?
Y que estás en S2015 y como en GS, ya que estás en S2015, dale a Smodule, dice Jorge Casar.
Claro, pero hay que diferenciar una cosa aquí, ¿vale?
Imagínate que el proyecto este lo vamos a utilizar en Node, ¿no?
Y pongamos que lo hacemos en Node 12.
Entonces, una cosa es el JavaScript al que te lo compila, del Async Await, por ejemplo, ¿no?
Que te lo deje con la versión de S2015, que sí que sea compatible con los navegadores.
Y otra cosa es como te utiliza los módulos.
En este caso, como no voy a controlar muy bien los ejercicios que nos pueden poner, pues lo voy a dejar así.
Luego ya veremos...
Bueno, de hecho, mira, aquí decía de cambiarle es 2015.
Pues eso, como no controlo muy bien que me voy a poner los ejercicios, por ahora lo voy a dejar así.
Y ya veremos si más adelante lo puedo cambiar mejor.
Porque yo soy súper amante de los módulos, pero por si acaso no la vamos a liar.
Vale, la de destino, la cambiarla por S2015, eso lo hemos hecho.
Actualiza el archivo para que el compilador guarde todos los archivos de JavaScript en una nueva carpeta.
Vale, o sea que buscamos la opción Outdir, que es como decirle dónde tiene que salir.
Aquí, Outdir.
Y dice que lo dejemos en...
Establezca el parámetro en Build.
Aquí pone que lo dejemos así, en Build.
No sé si esto funcionará.
Voy a probarlo, TSC.
Y a ver si me ha hecho la carpeta Build.
Sí, vale.
Pues ahí lo teníamos.
Ahí ya lo tenemos.
Vale, en el símbolo del sistema escribo a TSC, que es lo que acabo de hacer.
Yo que voy un poquito adelantado.
Veo el paso y ya me lo salto.
Compilación de TypeScript en JavaScript.
Vamos a agregar código JavaScript al archivo TypeScript y luego a compilarlo.
Copio y pego el siguiente código JavaScript en el editor module01.ts.
Vale.
Venga, nos lo copiamos así.
Esto básicamente es justamente lo que había hecho antes, pero bueno.
Tenga en cuenta que todavía no ha compilado el código.
No hemos hecho nada todavía.
Pero ya nos está diciendo justamente esto, ¿no?
Parámetro x que tiene implícito el any.
Me resulta curioso que ya te lo hice como un error.
O sea que está mal visto.
Bueno, tiene sentido que esté mal visto, obviamente.
Pero que me sorprende que de primeras ya es bastante estricto.
Bueno, tiene sentido.
Actualiza el código y lo reemplazamos por number.
Hacemos que esto sea el number.
Que esto es básicamente lo mismo que hemos hecho antes, pero bueno.
Ahora ya se ha ido el error y ahora funciona bien.
Venga.
Guardo el archivo y ahora vamos a compilarlo.
Pues lo compilamos con TSC y a ver cómo nos ha dejado JavaScript.
Vale.
Nos lo ha dejado limpio y aquí lo tenemos sin ningún tipo de error.
La gracia de esto es que ahora que ya tenemos los tipos, obviamente, pues ya lo que hemos visto antes, ¿no?
Que si pongo 3, pues me dice aquí, ¿eh?
Esto ha puesto que el argumento es un string y no es asignable al parámetro que tú has dicho que era un number.
Vale.
Perfecto.
Vamos avanzando.
Para cargar el archivo de configuración y compilar todos los archivos, ejecute TSC sin ningún nombre de archivo.
Esto lo hemos visto antes.
Abre el archivo módulo 01 y luego selecciona el botón dividir editor.
¿Vale?
Que son idénticos, con la única diferencia.
Bueno, esto básicamente lo que quiere es que miremos que son parecidos.
¿Vale?
Que este es el TypeScript y este es el de JavaScript.
Voy a cerrar esto.
Y que veamos que son casi idénticos excepto los tipos.
Vamos, que lo ha compilado.
Vale, perfecto.
Adición de un archivo HTML.
Ajá.
Escribe el nombre del archivo módulo 01.
Venga, vamos con el módulo 01.
No sé para qué es esto el módulo 01, como si fuese un HTML, pero vamos a fiarnos.
¿Vale?
Voy a abrirlo bien.
¿Quiere que creemos un HTML?
Pues creamos un HTML.
Vale.
Y en el HTML dice que carguemos justamente el módulo 01.
Venga, pues vamos a copiarnos todo el body este.
Esto lo ponemos por aquí.
Test de JavaScript, bla, bla, bla.
Bueno, esto es demasiado básico, ¿no?
Pero es para que veas que realmente funciona y ya está.
A ver, ahora dice que abramos el módulo 01.html.
Esta página llama al 01.js y está usada para testear.
Vale, perfecto.
Muy bien.
Vamos, que puedes utilizar el JavaScript que estás compilando.
Muy bien.
Activas herramientas de desarrollo y ya estás listo para la codificación en TypeScript.
Muy bien.
Para descargar el área de trabajo completa de Visual Studio Code del repositorio de GitHub,
para ejecutar la solución, primero de instalar el software siguiente.
Solución del ejercicio.
Esto quiere decir el ejercicio que hemos hecho nosotros ahora.
Vale.
Pues ya está, si ya lo hemos hecho.
¿No?
O sea, no tiene sentido que no lo volvamos a descargar.
¿O es que tiene más cosas aquí?
No.
Bueno, han cambiado esto un poco, pero ya está.
Prueba de conocimientos.
Bueno, empezamos ya con un examen.
A ver, me tenéis que ayudar a esto, ¿eh?
Me tenéis que ayudar.
¿Lo del error es por tu linter?
No.
Sí, no.
No.
O sea, el error que aparece en esa línea es por mi linter.
Este error que veis aquí...
Bueno, ahora no aparece el error.
Vamos a hacer que aparezca otra vez.
El hecho que salga aquí en el editor, esto es por una extensión que tengo que se llama
Error Lens.
Pero el que exista este error es porque TypeScript ya está instalado en Visual Studio Code.
Ya está aquí, ¿vale?
Entonces no tienes que hacer nada más.
Ya viene instalado y tal.
Vale.
¿Qué más?
¿Qué más me comentáis?
Node 12 soporta S-Module.
Lo sé, Jorge.
Node 12 y de hecho tengo Node 14 y todo.
Pero ya te digo que no lo hago por un tema...
Si es más que nada por si, yo qué sé, en algún momento me dice copia este archivo.
Mil cosas.
No es porque no se pueda.
Es por eso, más que nada.
¿Qué tipo de letra utilizas?
Cascade a Code.
Tengo un vídeo en YouTube que hablo de tipografías, por si os interesa.
¿Cuál es la relación entre TypeScript y JavaScript?
TypeScript es un supraconjunto de JavaScript, por si no me ha quedado claro.
No es exactamente lo mismo usar JavaScript y no es un subconjunto.
Es un supraconjunto.
Me encanta.
Supraconjunto.
¿Por qué es necesario compilar o transpilar código de TypeScript en JavaScript antes de usarlo?
No hace falta hacerlo.
El código de TypeScript se considera JavaScript válido.
TypeScript incluye características de código que no son compatibles con los exploradores.
Efectivamente.
¿Qué hace el comando mpm install menos g TypeScript?
Pues ocupar un montón de megas de mi disco duro.
Instala mpm para que se pueda...
No.
Instala compilador de TypeScript globalmente en el equipo.
Eso es lo que hace.
Muy bien.
Bravo.
400 puntos de experiencia.
Todavía no he subido de nivel.
Vale.
Resumen.
Muy bien.
Desbloquear logros.
Se pueden desbloquear logros.
Fíjate.
¿Qué tal lo estamos haciendo?
Bueno.
No está mal.
Bueno.
Se los no le digo nada.
Valinorja.
Muchas gracias por suscribirte con Prime.
Muchas gracias, Valinorja.
Espero que te esté gustando el cursillo que estamos haciendo de TypeScript.
Venga.
Declaración de tipos de variable en TypeScript.
Este ya parece un poquito más interesante que el anterior.
JavaScript es un lenguaje de tipos dinámico.
Y esto lo que nos va a hacer con TypeScript es que deje de ser de tipos dinámicos y que sean estáticos.
Que eso es lo que queremos.
¿Vale?
Pues vamos a ello.
Vamos al inicio.
Porque total requisitos los tenemos todos.
Venga.
Inicio.
Objetivos.
Ajá.
El sistema de tipos estáticos de TypeScript te permite describir la forma de un objeto.
Proporcionando una mejor documentación y permitiendo que TypeScript valide el código y que funcione correctamente.
Eso la verdad es que está muy bien.
Sobre todo me gusta mucho TypeScript para librerías de terceros.
Porque cuando las consumes es una delicia.
Es lo mejor.
La forma en que se forma un tipo se asocia a una entidad de lenguaje depende del tipo de entidad.
¿Vale?
Ya tengo instalado esto.
Así que nos vamos a siguiente.
Información general de tipos en TypeScript.
¿Vale?
La ventaja de TypeScript es que permite agregar tipos estáticos al código.
Perfecto.
Entonces.
Declaración de variables let y const.
En más script.
Ahora tiene dos palabras claves que es let y const.
Por si no lo sabéis.
Para declarar variables ya no hay que utilizar var.
Sino que siempre que podáis utilizar let y const.
A no ser que necesitéis var por X motivo.
Pero siempre que podáis utilizar let y const.
Y os olvidáis de las vars.
Aquí tenemos ya nuestro ejercicio.
Puede asociar tipos con variables mediante anotaciones de tipo explícitas.
O la inferencia de tipos implícita.
Explícita es que se la dice esto.
Ey.
Implícita es que TypeScript dice.
Vale.
Pues creo que es este tipo.
Aunque se recomienda.
Las anotaciones de tipo explícitas son opcionales en TypeScript.
Esto es lo que dice.
Claro.
Es opcional.
Pero claro.
Es mucho más probable que tú aciertes.
Que no a que sea implícitamente que crea el tipo que es.
Aunque entiendo que te puede encontrar un montón de problemas.
Sin que tú hagas nada.
Vale.
Vamos a meter estas declaraciones.
En lugar de hacerlo aquí en el área de juegos esa que no me gusta mucho.
Voy a poner aquí playground.ts.
Vale.
Y lo vamos a hacer aquí.
Vale.
Aquí tendríamos explícito.
Diciendo en el tipo implícito.
Porque ya declaras.
Al declarar la variable y tú asociarle el número.
Ya sabes que esto debe ser un number.
El TypeScript dice.
Vale.
Pues esto será un number.
Claro.
Sin iniciarla.
Entiendo que debe ser más problemático.
Y hasta que tú no le asignas algo.
Pues no debes saber qué tipo es.
Vale.
TypeScript ahora trata la variable x como un número.
Ta, ta, ta.
Claro.
Dice x es de tipo número.
Claro.
Si yo ahora aquí pongo hola.
Pues obviamente esto me dice un error.
Que el tipo de string no es asignable al tipo número.
Pero aquí me imagino que pasara lo mismo.
¿Veis?
Aunque yo aquí no le he puesto que es del tipo número.
Si le intento asignar un string.
Claro.
Me dice.
Oye.
No.
Es que el tipo string no es asignable al número.
Porque tú le habías asignado al número.
Pero aquí.
Claro.
Aquí no.
No sé.
La primera vez no pasa nada.
Y la segunda vez.
Tampoco.
Porque no ha podido inferir desde el principio cuál es el tipo que tenía.
Claro.
Esto es el que entiendo que puede ser un poco problemático.
Porque aquí sí que te va a dar errores.
Pero en este no te lo va a dar.
No es capaz de inferir cuál es el tipo.
¿Vale?
Ese sería el tema.
Ese sería el tema.
¿Vale?
Muchas gracias por esos 100 bits.
Muchas gracias TheRollersHark.
Te contesto ahora cuando termine esta página.
¿Vale?
Esto más o menos es lo que os he explicado.
Que es lo que hemos hecho.
¿Veis?
Aquí explica lo de que a la Z que no tenía un valor desde el principio.
¿Vale?
Que no ha podido inferir cuál era el tipo.
Ha aceptado ambos valores.
A ver.
Dice que esto funciona de la misma manera que en JavaScript.
Porque la variable Z ahora puede aceptar cualquier valor que se le haya asignado.
JavaScript ha inferido que Z es de tipo Any.
Claro.
Infiere que el tipo es Any.
O sea.
Solo infiere al principio.
No una vez que tú le asignas el valor.
Pero dice.
Dice.
¿Por qué debería inferir los datos?
¿Mediante inferencia de datos obtienes alguna ventaja de la comprobación?
Comprobación de tipos estáticos.
Claro.
Porque tú imagínate que tú tienes un montón de código JavaScript.
De esta forma.
¿No?
Tienes un montón de.
Así.
Un montón de JavaScript.
Esto ya lo puedes pasar por TypeScript y ver qué problemas puedes tener.
De hecho es bastante interesante.
Que tu JavaScript.
Sin ningún tipo de cambio.
Te pueda llegar a inferir problemas que pueda tener tu código.
¿Vale?
Tipos y subtipos en TypeScript.
¿Vale?
¿Y los tipos primitivos son exactamente los mismos que tenemos en JavaScript?
No.
Tenemos booleano.
Número.
String.
Enumeración.
Enumeración.
Esto es un tipo primitivo que no existe en JavaScript.
O sea que esto es nuevo.
Luego tendríamos no válido.
Que entiendo que esto también es uno nuevo.
O sea nuevo respecto a JavaScript.
No válido.
Luego tendríamos tipos de objeto.
Clase.
Interfaz.
Matriz.
Y literales.
La clase sí que sería parecida a lo que sí que tenemos en JavaScript.
Y tipo parámetros.
Estos serían los tipos que tenemos en TypeScript.
Y luego tendríamos null y undefined.
Qué fea, ¿no?
Es esta imagen.
Es súper rara esta imagen.
Vale.
Los tipos primitivos.
Boolean.
Number.
String.
Void.
Null.
Void.
Void es el no válido.
Null y undefined.
Junto con enumeración definida para usuarios tipo enum.
La enum puede estar muy bien.
Void existe únicamente para indicar la ausencia de un valor.
Como que no se devuelve ningún valor.
O sea que está bien porque esto sería undefined en JavaScript.
O sea que veremos esto cómo funciona.
Vale.
Y los objetos es los que hemos comentado.
Perfecto.
Así que la siguiente unidad.
Tipos primitivos en TypeScript.
Pues ahora lo veremos.
Y vamos a ver lo que quería.
TheRollerShark.
Hola.
¿Cuál crees que es la manera más eficaz de procesar una gran cantidad de datos sin bloquear el thread principal?
He probado WebWorkers para generar un árbol a VL.
Pero tiene ciertas limitaciones.
Y no se pueden devolver cosas de Destructive Clone Algorithm.
A ver.
Es que claro.
Te iba a decir WebWorkers.
WebWorkers es lo mejor.
Estoy pensando en WebWorker Post Message Surma o Jake.
Es que a lo mejor una cosa que te puede venir bien es echarle un vistazo a Comlink.
Voy a enseñarlo por aquí.
Comlink.
Bueno, aparte de este artículo de Surma que es genial.
Comlink es como una pequeña librería para utilizar WebWorkers.
Y justamente Google lo está utilizando para el proyecto este que era un juego bastante interesante y que iba bastante, bastante bien.
Además, este Comlink lo que te permite es que puedas enviar todo tipo de datos.
Bueno, todo tipo de datos.
Supongo que tiene algún tipo de limitación.
De limitación, pero no solo es tan limitado como lo que tenía antes de que tenías que hacer el Post Message y tal.
Entonces, yo le echaría, si no le has echado un vistazo, te recomiendo que le eches un vistazo a este porque Comlink, ya te digo que Google lo está utilizando en algunos de sus proyectos.
De hecho, no sé si en Squash lo están utilizando, que es bastante potente este, Squash, a la hora de optimizar imágenes y va muy bien.
Así que échale un vistazo.
Pero yo creo que esa es la mejor forma, ¿sabes?
Si tienes muchos datos, lo mejor es WebWorkers, o sea, sin ningún tipo de duda.
No sé hasta qué punto se puede...
¿Ves aquí que es con Atable Listener y tal?
Mira, Prox.
Este es el juego.
Prox.
Este es el juego que tiene WebWorkers y que va súper bien en dispositivos antiguos y tal.
Porque utilizan WebWorkers.
Así que échale un vistazo a eso, al Comlink.
¿Ves? Aquí te lo explica por qué utilizar un Comlink.
Te lo dejo por el chat, el link.
Y nada, a ver si te ayuda de alguna forma.
Porque ya te digo que ellos se encontraron justamente con este tipo de problemas.
De no poder enviar todo tipo de datos.
A ver si esto te ayuda, ¿vale?
The Roller Shark.
Ay, qué bien.
Qué bien estamos.
Todo en Microsoft Learn es gratis, creo.
Creo que sí.
Creo que sí.
Mis viernes no sean iguales sin ver al Messi del front en echar código.
Qué grande.
El curso es totalmente gratis, ¿eh?
Os lo paso por aquí.
A ver dónde lo tengo.
¿Dónde lo he dejado?
Vale.
Compleación de aplicaciones.
Os dejo otra vez el link, ¿vale?
Y os leo.
Os leo, os leo.
Dice, se declara como Eni.
Claro.
Eni es el mejor amigo de todos, hombre.
O el peor enemigo, ¿no?
Es el mejor amigo porque se lo come todo con patatas.
Pero el que se lo coma todo con patatas, justamente, puede ser negativo, ¿no?
¿Cómo se llama extensión de base al cuero que se muestran los errores?
Se llama Error Lens.
Es la que estoy utilizando.
Error Lens.
¿Void existe en JS?
Sí, está Cadogan.
¿Void existe en JS, pero no existe como tipo?
Es diferente.
¿Void no es un tipo en JS?
Esa es la diferencia, ¿eh?
Yo no digo que void no exista en JS.
De hecho, lo que hace void, o sea, se utiliza más como, no como tipo, sino que sería una
palabra que lo que hace es siempre devolver null o undefined o nada, ¿sabes?
O sea, tú puedes utilizar void y poner lo que sea.
Y lo que te hace es convertirlo, no sé si en null o undefined, nada, no me acuerdo.
Lo podemos mirar en un momento.
Void 1.
Y lo que hace es, void 1, ¿ves?
Te devuelve undefined.
Void 2.
Pues eso.
Pero no es un tipo, es diferente.
Por eso digo que no estaba en JavaScript.
¿Recién está empezando el curso?
Estoy empezando ahora, o sea, que no os preocupéis.
Estoy viciado tus podcasts, ojalá vuelvas a hacerlos.
Muy pronto vamos a tener un par nuevos.
Muchas gracias, lo voy a probar.
Otra opción sería con set timeouts, pero me parece una guarrada.
Es una guarrada.
Si puedes utilizar web workers, mejor.
¿Debería tiparse todo?
¿Desde funciones, componentes, react, variables, acciones, etcétera?
Diablita, buena pregunta, Diablita.
Espero que no vengas desde el infierno a preguntar, pero lo que sí.
Yo creo que hay que intentar, esto es un problema que le veo a TypeScript y es el hype en la que se lleva la gente.
Hay que tener en cuenta, yo TypeScript es una herramienta muy potente, pero que puede hacer que, aunque es verdad que desarrollas con más garantías,
puede hacer a veces que si empiezas a meterlo en todos los sitios, todos los sitios, todos los sitios, te vaya costando cada vez más mantenerlo,
te den muchos problemas y tal.
Sobre todo en temas de RIA que he visto que, he visto en proyectos, de amigos míos me los enseñan, los charlamos y tal,
de que cuesta, ¿no?
Entonces la gente tira al final por el ENI y tal.
Yo creo que hay que añadirlo donde te vaya a dar más valor, ¿sabes?
Donde el coste sea menor que la ventaja que te da y no ponerse a añadirlo a saco y ya está.
Bueno, no sé cómo puedes tener un montón de Kindles en la caja de atrás y no comértelos.
Aquí, ¿no?
Aquí están, aquí están.
Son solo un modo de emergencia.
Void casi no se usa.
En TypeScript no lo sé, me imagino que se usará más, pero en JavaScript no.
La función regresa un número, pero se puede imponer que las funciones devuelvan un tipo de dato.
Vale.
Vale, pues nada, vamos a seguir.
Vamos a seguir por ahí.
Vamos a seguir.
Vamos a seguir.
Tipos primitivos en TypeScript.
Tenemos el tipo booleano, ¿vale?
Perfecto.
True o false.
Tipos numéricos.
Esto ya lo tenemos.
Mira, tenemos vkint.
Este es interesante, vkint.
Vkint.
Este también existe en JavaScript.
No es una cosa que sea solo de TypeScript.
Y al final lo que te permite son enteros que de otra forma no podría representar con el entero normal de JavaScript.
Así que más o menos esto ya lo tenemos.
El string, por supuesto.
Interesante.
TypeScript también puede usar cadenas de plantillas.
O sea, vale, que puedes utilizar template strings y que también es del tipo string sin ningún problema.
Tipos void, null y undefined.
¿Lo ves?
JavaScript y TypeScript tienen dos valores primitivos que se usan para indicar un valor ausente o con inicialización anulada.
¿Vale?
El inicialización anulada es null.
Y valor ausente es undefined.
Lo digo porque la han puesto al revés.
Estos tipos son más útiles en el contexto de las funciones, por lo que se tratarán con más detalle en el módulo posterior.
Pero no hablan de void todavía.
Bueno.
Vamos con el ejercicio de las enumeraciones.
Que aquí ya entra un poco la chicha.
Aquí entra un poco la chicha de TypeScript.
Y este es uno de los tipos que a mí me gustan mucho de TypeScript.
Que ojalá tuviese JavaScript.
Ojalá.
El tipo de enumeración.
Una incorporación útil al conjunto estándar de tipos de datos de JavaScript es el tipo de enumeración o enum.
Las enumeraciones al final lo que ofrecen es una manera sencilla de trabajar con conjuntos de constantes relacionadas.
Imaginemos, por ejemplo, los días de la semana.
Los días de la semana sería un enum.
Porque son strings, pero son limitados.
Monday, Tuesday, Wednesday, tal.
Un elemento enum es un nombre simbólico para un conjunto de valores.
Pues los días de la semana.
Las enumeraciones se tratan como tipos de datos y se pueden usar a fin de crear conjuntos de constantes para su uso con variables y propiedades.
Genial.
Siempre que un procedimiento acepte un conjunto limitado de variables, considera la posibilidad de usar una enumeración.
Es que esto es genial.
De hecho, en JavaScript tú puedes hacer enums, pero son un poco más de aquella manera.
O sea, yo podría tener un enum que aquí pongas Monday y luego aquí le puedes poner cero, luego Tuesday.
Y al final esto de alguna forma es un enum porque tú puedes hacer esto, punto Monday, y sacar el weekday así.
De alguna forma aquí, en este aspecto, está funcionando como si fuese una enumeración.
Porque aquí tendrías enumerados todos los días y los podrías utilizar de esa manera.
Pero en TypeScript esto es mucho mejor porque al final aquí yo puedo hacer enums, punto, whatever, y esto no me lo está controlando.
No me está controlando que weekday solo puede utilizar uno de los que añada aquí.
Entonces eso ya lo tendrías que hacer en Runtime.
Así que vamos a seguir con los enums, a ver qué se cuenta.
Mira, permite reducir los errores, facilita el cambio de valores en futuro, facilita la lectura del código, garantiza la compatibilidad con versiones posteriores.
Vamos a crear nuestro primer enum.
Venga, crea un elemento enum para representar un nuestro escenario, para ello escriba lo siguiente.
Vale, esto va, por ejemplo, vamos a ponerlo aquí.
Vamos a tener un enum y le llamamos contract status.
Status.
Voy a quitar esto.
Claro, un enum es muy interesante también para el estado en el que se puede encontrar una cosa porque los estados, que normalmente los puedes hacer como strings o como números o como ideas o lo que sea, con los enums es súper genial porque queda mucho más fácil de leer.
Un contract status puede ser permanente, puede ser temporal o puede ser que sea una beca.
Vale, estos son los estados que tendría el contract status.
De esta forma, ahora podemos declarar una variable que sería el estado que tiene un trabajador, ¿no?
Employee status.
Y esto, lo que le podemos decir es que solo puede ser una de estas tres.
El permanent, el temp o el apprentice.
O sea que el contract status le vamos a decir que es del tipo contract status.
Esto es el tipo de datos enum.
Y le vamos a añadir uno de los valores.
Claro, si yo aquí pongo dos, pues ya me va a decir, uy, me debería decir que esto no funciona.
Pero ya veo que se lo ha comido con patatas.
A ver, ¿por qué?
Contract, lo he puesto bien, ¿no?
Contract status, sí.
Ah, pues, ah, claro.
Qué interesante, qué interesante esto.
Claro, es que el dos al final, aunque es un número, hostia, pero yo esto no me lo esperaba, ¿eh?
Claro, esto a lo mejor lo que hace es que sea uno de los que ves aquí.
Esto puede ser bastante curioso.
Pensaba que, claro, puede ser 0, 1, 2.
Puede ser apprentice.
Si me pones 5, bueno, igual se lo traga igual.
Pero pensaba que a lo mejor esto fallaría.
En cualquier caso, la forma correcta sería decir, contract status, punto.
Además, fíjate lo bien que aparecen aquí.
Apprentice, permanent y temp.
O sea, ya te sale un auto completado para saber cuáles son los estados que puedes aceptar.
Pues vamos a decir que está en temporal por ahora, ¿no?
Y luego, bueno, pues si ponemos un console.log del employee status, voy a hacer esto en
run.js, porque run.js creo que tiene soporte para TypeScript.
Vale, ahí está, mira.
Esto es run.js, run.js es otro editor, lo que te permite ejecutar al vuelo JavaScript y
TypeScript.
Y aquí a la derecha, pues, tienes la consola.
He añadido aquí TypeScript, he puesto el enum, y entonces aquí decimos contract status,
le decimos contract status, punto.tem.
Fíjate que esto es 0, 1, ¿no?
Esto sería el 0, esto sería el 1, y esto sería el 2.
Entonces, cuando hago el console.log del employee status, como le he dicho que es el punto
temp, fíjate que me pone el 1.
Claro, si yo le pongo aquí, whatever, no sé, serán define, claro.
Pero si vamos aquí, ves que aquí sí que me falla, me dice, oye, que la propiedad whatever
no existe en el tipo tal.
O sea, que esto te ayudaría.
El problema de run.js es que puedes ejecutar TypeScript, pero no te hace el check de TypeScript.
Pero bueno, por eso, cuando yo ponía aquí el 2 directamente, como esto es un enum, que
al final lo que está como transformando es a números, claro, cuando digo el 2, en realidad
es como si estuviera diciendo contract status apprentice.
Pero no es la forma correcta de utilizar esto.
La forma correcta sería hacer así, ¿no?
Punto.tem, por ejemplo.
Y esto sería un 1 ahora.
Esta sería la forma correcta.
Ahí está.
Es tan genial.
O sea, los enums me parece lo mejor que tiene, sin ningún tipo de duda, TypeScript, en
el sentido de que es lo primero que aprendes y lo que te da un montón de potencia, ¿sabes?
A tu código.
De hecho, Proposal, JavaScript, yo creo que había una Proposal.
Esta es de hace tres años.
Hacía tres años.
Pero, ¿veis?
Había una Proposal para añadir esto en JavaScript.
Y yo creo que, mira, aquí, días de la semana.
Es que este ejemplo de días de la semana es muy, muy, muy típico.
Muy típico.
Claro, el tema es que es muy útil.
Es demasiado útil.
Yo creo que eventualmente, a ver, enum, Proposal, a ver si está.
Enumeration, no.
Proposal for the enum keyword.
En algún momento yo creo que lo añadirán porque es que es demasiado útil y no tiene
sentido que esto no se pueda hacer en lenguaje de forma nativa sin necesitar TypeScript porque
es verdad que es un tema de, sí que es verdad que es un tema de tipos, pero esto, imagínate, en JavaScript podríamos utilizarlo también así.
Esto debería ser posible hacer también sin necesidad de TypeScript.
Sensebeu.
Muchas gracias por suscribirte, Sensebeu.
Espero que sí que tengas voz y que estés mucho mejor.
Los haters dirían que en Java existe hace años.
Sí, no, en Java existen un montón de cosas, claro, pero bueno, Java no se puede ejecutar de forma nativa en el navegador y JavaScript sí.
Y, a ver, es que las comparaciones esas son un poco, a ver, JavaScript juega con una desventaja enorme respecto a un montón de lenguajes de programación
porque tiene que ser totalmente retrocompatible con todas las versiones anteriores y entonces su evolución puede ser un poco más costosa que otros lenguajes.
¿Qué dices? Ahora compilo con la versión A, otro con la 2, otro con la 14, o sea, es diferente. Por eso, con un poco de desventaja.
Venga, vamos a seguir con el tema este.
A ver, ¿qué más?
Voy a poner musiquita.
Vale, ahora dice, esto ya lo he ejecutado, dice, de forma predeterminada los valores en um comienzan con un valor 0.
Esto lo hemos visto, ¿vale?
Por lo que perman es 0, temp es 1, esto justo os he puesto aquí el comentario y todo para que lo veáis, ¿no?
Esto es 0, esto es 1 y esto es 2.
Perfecto.
Pero parece ser que tú, si quieres, puedes añadirle que empiece a partir de otro valor.
Si quieres que los valores empiecen con un valor diferente, lo tienes que especificar en la declaración.
Realiza esto.
O sea, que ahora aquí yo le puedo decir que el perman es 1 y ahora será 1, 2, 3.
Empezará a partir del 1.
Tú le puedes decir el número por el que empieza.
Esto es muy útil, parece una tontería esto, pero esto puede ser muy útil por diferentes razones.
Una de ellas es que hay veces que en las APIs, en las bases de datos o lo que sea, por ejemplo, en mi empresa tenemos property types.
¿Vale?
Property types.
Property types, por property entendemos una propiedad.
Puede ser una casa, un garaje, un lo que sea, ¿no?
Entonces, el tema es que para nosotros empezamos a partir del número 99.
¿Por qué?
No lo sé.
No tengo ni idea.
Pero la house empieza por la 99.
El garage empieza en la 100.
Entonces, es genial porque esto nos permitiría ya directamente pues hacer esto, ¿no?
Y ya lo tendríamos así ya genial.
Así que está bien saberlo.
Ahora vuelve a ejecutar y bueno, sí, veríamos que ahora sería 2.
O sea, este código, si yo ahora lo ejecuto aquí en Ranges, veremos que esto ahora debería ser un 2.
¿Vale?
Perfecto.
Porque empezamos el 1, le he dicho temp y temp es 2.
Y que dice, para mostrar el nombre asociado a la enumeración, podemos usar el indexador proporcionado.
¿Vale?
O sea, para el nombre asociado.
Para el nombre asociado, puedes hacer console.log, contract, status y le pasamos el employee status.
O sea, es el string.
Fíjate que cuando estábamos hablando de esto, es exactamente lo mismo que hemos hecho antes, ¿no?
Que hemos hecho, os he dicho, en JavaScript esto se puede hacer.
Porque al final nada te impide hacer esto.
¿Vale?
Y esto es exactamente lo mismo.
Es la misma estructura.
Esto funcionaría sin ningún tipo de problema, evidentemente perdiendo el tema de los tipos.
No podríamos tener el tema de tipado y tal, ¿no?
Pero esto podría funcionar.
Lo podríamos hacer funcionar sin ningún problema.
Pero, bueno, está escribiendo más interesante.
¿Vale?
Muy interesantes los enums.
Vamos a seguir, va.
A ver, ya sabemos enums.
¿Qué metemos ahora?
Any y unknown.
Venga, hay ocasiones en las que vas a necesitar trabajar con valores que son desconocidos en el momento de desarrollar el código
o que son de un rango posible reducido de tipos de valor.
En ese caso, puedes utilizar any y unknown.
Ostras, tengo curiosidad cuál es la diferencia entre any y unknown.
Así como usar la selección de tipos y las restricciones de tipos para mantener el control.
¿Vale?
Esto es.
El any es cualquier tipo.
Es un tipo que puede representar cualquier valor de JavaScript sin ninguna restricción.
Es útil si esperas un valor de una biblioteca de terceros, entrada de usuario, me imagino que APIs que no controles,
ya que el tipo any permite volver a asignar distintos tipos de valores.
Claro, tú empiezas y tienes el any que empieza con un string, luego puede ser un número, luego lo que sea.
Tal y como se ha mencionado antes, el uso del tipo any permite migrar gradualmente el código de JavaScript.
Claro, porque de esta forma podríamos hacer que al principio casi todo pudiese ser que sea, claro, any en JavaScript.
Y a partir de ahí tú ir añadiendo donde tú veas el any, decir, ah, no, esto es un número.
Entonces lo pones.
Es una forma muy fácil de hacer una migración gradual, pasarlo todo a any y luego ya te buscarás la vida.
Cuando se compila este ejemplo no se produce un error porque está el any.
Y con el any, pues primero es un número, luego es un boleano, luego es un string, todo ok, ok, ok.
El tipo any opta por no recibir la comprobación de tipos y no le obliga a realizar ninguna comprobación.
Vale, o sea que no hace comprobaciones.
El uso del tipo any permite llamar a lo siguiente, bueno, como lo hemos visto.
El primero un número, boleano, luego un string.
Las instrucciones siguientes generan errores o comportamientos inesperados en tiempo de ejecución.
Importante, en tiempo de ejecución.
Esto también es súper importante, que no lo ha comentado el curso, pero tiene que quedar esto muy, muy claro.
Las comprobaciones de tipos que hace TypeScript son solo en tiempo de compilación, de modo estático.
O sea, en tiempo de ejecución, ves que pone aquí comportamientos inesperados en tiempo de ejecución.
En tiempo de ejecución no hace ningún tipo de check sobre los tipos, ¿vale?
No te avisa y te dice, oye, hay un error de este tipo.
No, ya ha pasado demasiado tarde.
Ya no hace ningún tipo de chequeo en ese sentido, ¿vale?
Súper importante porque hay gente que cree que hace chequeo de tipos en runtime y no lo hace.
Tiene sentido que no lo haga.
Recuerde que toda la comodidad de any se produce a costa de perder seguridad.
Vale, genial.
Me quedo más tranquilo.
Tip unknown.
Aunque es flexible, el tipo any puede producir errores inesperados.
Para solucionar esto, TypeScript ha presentado el tipo unknown.
Unknown es similar al tipo any, en que cualquier valor se puede asignar al tipo unknown.
Pero no se puede acceder a las propiedades de un tipo unknown, tampoco se puede llamar ni construir.
Vale.
Esta ahora entiendo la diferencia.
Entonces, vamos a verlo en código.
Vamos a verlo en código aquí.
Tenemos el random value que es del tipo unknown.
Como podemos ver aquí, yo lo puedo ir cambiando de un número a un booleano, a un string.
Yo puedo hacer todo esto sin ningún problema.
Pero entiendo que si intentas ir a randomvalue.name, ¿vale?
Aquí tenemos que no se puede acceder a una propiedad de un random value.
Aunque tú hicieses esto.
Aunque hicieses esto.
¿Vale?
¿Ves?
Aunque tú tengas asignado a esta variable un objeto con una propiedad name, fíjate que dice el objeto que tú tienes aquí, random value, es unknown.
Y por lo tanto, no puedes, no te deja acceder.
Esto te petaría.
Esto mismo pasaría con un método.
GetName, por ejemplo.
O sea, cualquier propiedad o método al que intentes acceder de random value te va a dar un error con el unknown.
Si le ponemos any, sí que va a funcionar.
Pero si le ponemos unknown, no.
Esa es la diferencia.
Esa es la diferencia.
Ah, y tampoco se puede, o sea, en sí mismo tampoco se puede ejecutar.
Claro.
¿Por qué hacen esto?
Ahora voy entendiendo más.
¿Por qué hacen esto?
Esto lo hacen porque justamente te está dando una cierta protección en tiempo de ejecución.
Recuerda lo que acabo de decir, ¿no?
Que estos chequeos no los hacen en tiempo de ejecución.
Por lo tanto, TypeScript, si tú le pones aquí un any, pues esto se lo come con patatas y ya está.
Pero lo que estás haciendo aquí con el unknown es que estás como protegiéndote de, oye, ya que no lo tienes claro de qué tipo es,
no pasa nada si tú vas haciendo esto.
Lo asignas, le asignas un valor, no pasa nada.
Pero como no tienes claro qué tipo es, no te voy a dejar que hagas esto.
Ni que lo ejecutes, ni que accedas a una propiedad, ni nada.
Me imagino que tampoco podrías acceder a un, ¿ves?
No se puede acceder a una posición.
Porque este tipo de cosas pueden petar.
Esto peta.
O sea, esto si no existe, si random value es un booleano, esto peta.
Si random value es, por ejemplo, un booleano, esto peta.
Esto lo mismo, peta, y esto pues peta, ¿vale?
Entonces por eso lo hacen.
Pero claro, en cambio esto, este random value, si es un string y tú haces random value más 2,
esto no peta.
No queda bien, pero no peta, es diferente.
Por eso, ahí es donde está la utilidad.
No sé si ha quedado claro, pero a mí me ha quedado bastante cristalino.
La nota, diferencia principal entre any y unknown, es que no se puede interactuar con una variable del tipo unknown.
Y si lo hace, se genera un error del compilador.
En cambio any, puedes hacer todo lo que te dé la gana.
Venga, aserción de tipos.
¿Qué es esto de la aserción de tipos?
Esto es que si necesitas tratar con una variable con un tipo de datos diferente, puedes usar una aserción de tipos.
Que esto lo que dice a TypeScript es que ha realizado cualquier comprobación especial que necesitas hacer antes de llamar a la instrucción.
O sea, lo que le estás diciendo básicamente al compilador o transpilador de TypeScript es
no te preocupes que yo sé lo que hago.
Básicamente es esto, ¿no?
Indica al compilador, confía en mí, sé lo que estoy haciendo.
Vale, perfecto.
Una aserción de tipos es como una conversión de tipos en otros lenguajes.
Pero no realiza ninguna comprobación especial.
Claro, ¿por qué?
¿Por qué es esto?
Cuando tenemos este random value, esto de aquí, lo que le vamos a decir es, vale, no lo sé.
En este punto cuando lo creo no lo sé.
Pero, voy a editar esto.
Lo que puedes hacer es random value como string to uppercase.
Y entonces ahora sí que funciona.
Porque le estás diciendo, no, no, confía que ahora yo sé en este punto que el random value es un string.
Y entonces, ¿qué hace TypeScript?
Y dice, ah, vale, si esto es un string, entonces sí puedes llamar al to uppercase.
Es como que antes de poder ejecutar, porque si no, no te deja.
O sea, si tú haces esto, esto no te deja.
¿Ves?
Que sale aquí en rojo, object type unknown.
Entonces, para que te deje tienes que decirle, vale, random value, trátalo como si fuese un string.
Y entonces te dejo acceder al to uppercase.
¿Vale?
Así que eso sería básicamente la aserción de tipos.
Ah, mira, hay dos tipos de hacerlo.
Bueno, una con el as, que es el que acabo de ver, y otra sería así.
O sea, una sería así.
Y la otra sería quitando esto y poniéndolo aquí.
Me gusta un poco más la otra.
La otra, ¿no?
Bueno, aquí le falta un punto y coma, que si no, no...
Estas dos líneas son iguales.
Es como para forzar el tipo que tiene la variable, en este caso.
¿Vale?
As es la sintaxis preferida.
Sí, también la mía.
También la mía.
En el ejemplo siguiente se realiza la comprobación necesaria para determinar random values en un elemento string antes de usar la aserción de tipos.
Hmm.
Vale.
Vale.
Vale.
Entonces, aparte de esto, esto sería como para indicarle, sin hacer en tiempo de ejecución la comprobación, decirle, vale, random value es un string.
¿Vale?
Ah, pues te dejo ejecutar el to uppercase.
Pues hay otra forma más de hacer esto.
Y es decir, utilizar el type of.
Sí, claro, si tú le dices, si random value es del tipo string, entonces voy a hacer la ejecución, por ejemplo, tu lowercase.
Y esto te deja.
Pero fíjate que si esto lo pongo fuera, igual me peta.
¿Vale?
¿Ves?
¿Por qué?
Porque TypeScript está detectando que estás haciendo un chequeo del tipo de dato de random value antes de ejecutar el método tu local lowercase.
O sea, es como un control, ¿no?
Si aquí dices, aquí no sabes cuál es el tipo, pues te va a decir que es un error.
Entonces, en estas dos líneas anteriores le habíamos como forzado a decirle, no, no, yo sé que es un string.
Vale.
Pues en este caso es un poco más allá, porque este código sí que se va a ejecutar en tiempo de ejecución.
¿Vale?
Esto sí que se va a ejecutar en tiempo de ejecución.
De hecho, si yo compilo esto, lo voy a compilar.
Lo voy a compilar.
¿Vale?
Lo compilo.
Y si vamos al JavaScript Playground, ¿veis?
Que se ha quedado aquí este if.
If, type of, random value, no sé qué.
O sea, este código sí que se queda ahí.
Pero este código que habíamos hecho antes, si lo compilo, fíjate que no hace ninguna comprobación ni nada.
O sea, es, digamos que esto es para que el compilador no te dé problemas y esto es para que el código, cuando lo ejecuta el cliente, tenga un mejor control.
Y entonces, cuando TypeScript detecta de, ah, vale, genial, en este caso ya tienes una comprobación, vale, pues entonces sí que lo puedes utilizar porque lo estás comprobando en el código.
Me parece genial, ¿eh?
Me parece genial.
¿Tienes que usar punto y coma?
No, no tengo que usar punto y coma.
Bueno, en este caso sí tengo que usar punto y coma, ¿eh?
¿Por qué?
¿Por qué tengo que usar aquí punto y coma?
Este es un ejemplo muy interesante.
Aquí hay que utilizar punto y coma, fíjate, ¿no?
Que dice, esta expresión no se puede llamar.
Aquí hay que utilizar punto y coma porque como aquí tienes un paréntesis, bueno, aquí no, como aquí empieza por paréntesis, cuando no pones un punto y coma, JavaScript lo lee así.
Se cree que es todo una línea.
Entonces, este es uno de los casos en los que hay que poner punto y coma.
Este es uno de los casos donde hay que poner punto y coma.
Normalmente, esto en el linter, lo que pasa es que no tenemos linter, ¿eh?
Si tuviera un linter, esto nos lo hubiera detectado y hubiera puesto hasta el punto y coma solo.
Normalmente se pone incluso aquí.
¿Por qué?
Porque hay veces, cuando no trabajas con puntos y comas, ¿ves?
Yo puedo ir quitando puntos y comas y tal.
Aquí lo necesito también porque si no me fallaría el otro.
Cuando no trabajas con puntos y coma y te sabes esta regla, que esto te lo hace estándar automáticamente.
O sea, tú guardas el fichero y no se queja, sino que te pone punto y coma y ya está.
Pues eso.
Pero bueno, por ahora lo vamos a poner al final para que quede más claro y no liaros.
Porque al final lo importante es entender lo que está haciendo esto, ¿eh?
A ver, ¿qué me comentáis?
Es que TypeScript son solo en los ID.
Es que TypeScript son solo en los ID.
Ah, vale, me quedó más claro.
Solo sirve en los ID.
¿En los ID?
Ah, no me he quedado...
Es que solo en los ID.
¿Qué significa eso?
No he entendido.
Samugarrón.
¿Qué quiere decir?
Hidratación.
Me hidrato.
Solo en Visual Studio.
¿Qué hago con los 50.000 seguidores?
Hemos llegado a los 50.000 seguidores.
No sé si lo he dicho.
Pero hemos llegado a los 50.000 seguidores.
No, ya somos 50.000.
¡Oh, my God!
¡Oh, my God!
¿Cómo esto sigue así?
Pues ya somos 50.000 en YouTube.
Muchas gracias a todos.
¿Qué hacemos para celebrarlo?
¿Qué hacemos?
He pensado en un clon de TikTok en directo en YouTube.
¿Hasta dónde lleguemos?
He pensado...
Dice TikTok con Next.js y TypeScript.
O sea, con TypeScript me costaría, ¿eh?
Crea una startup para los 50.000.
¡Me cago en la hecha!
¡Qué difícil eso!
¿Qué más podemos hacer?
Alguien había dicho un Amazon, un YouTube...
Me parecen buenas ideas.
Montar todos los vídeos de Twitch.
Ya ves.
A ver, en el canal secundario tengo.
Una startup open source.
Bueno, a ver.
Quiero seguir con mi proyecto Menea Dev.
Que lo seguiremos en Twitch, por supuesto.
Una red social con tus seguidores.
Bueno, ahí tenemos Discord.
¿Quién era que se apunta a Discord?
Que ya somos 2.500 en la comunidad de Discord.
Así que nada, apuntaos.
Que ahí estaremos.
Bueno, si tenéis ideas las vais dejando por ahí, ¿vale?
Uy, ¿qué ha pasado aquí?
Hay un hueco aquí.
Ha habido un hueco.
Vale.
Venga, vamos a seguir.
Ya sé que quizás ya lo dijiste, pero ¿qué te haría elegir TypeScript en un proyecto en vez de JavaScript?
Buena pregunta.
Muy buena pregunta, Nuri.
Muy buena pregunta.
A ver.
A ver.
¿Qué es lo que me haría?
Por ejemplo, si fuese una biblioteca que tuviese que consumir gente...
¿Sabes una biblioteca que tuviese que hacer?
Seguramente intentaría añadirle TypeScript.
¿Por qué?
Eso te hace tener una documentación muy potente.
Otro sitio donde pondría TypeScript, justamente donde estuviera teniendo muchos problemas con los tipos.
Otro sitio donde lo añadiría es donde tenga objetos que me hablen del negocio muy claramente.
Por ejemplo, en un sitio donde estás constantemente hablando de objetos de tu dominio, pues eso, contract status.
Ostras, pues un contract status, tener un enum es una maravilla.
Cosas así donde puedas plasmar tu negocio en la documentación de los tipos de TypeScript.
Hombre, pues es genial, ¿no?
Porque así todo el mundo habla el mismo idioma.
Al final, cuando alguien...
Imagínate que tenemos un Facebook.
Estamos haciendo un Facebook.
Pues cuando alguien habla de un post, ¿vale?
Un post, que sería el mensaje que alguien hace y que puede tener comentarios y puede tener likes y todo esto.
Pues imagínate tener el tipo post y que ya tengas ahí todos los atributos que puede tener un post.
Y cómo se dice likes.
O cómo lo llamamos.
Likes, fabs, no sé qué.
Bueno, pues likes.
Claro, tenerlo todo documentado y que todo el mundo se tenga a referir a lo mismo con el mismo contrato.
Ahí también seguramente lo haría.
Yo creo que ahí es donde seguramente lo metería.
Pero tendría cuidado también de no meterlo en...
No sé.
Meterlo por meter ahí sin ningún tipo de control.
Porque al final puede ser un poco problemático.
En herramientas de Node seguramente seguro que lo metería.
Todos los vídeos live de Twitch serán montados en Midulife.
En Midulife te entran en Twitch directamente.
Ah, en Midulife te refieres en YouTube.
En YouTube tengo el Midulife.
Es mi canal secundario que ya somos 1210.
Bueno, voy subiendo algunos y sí que voy a intentar subir el resto.
Voy a intentar a ver si este fin de semana me da tiempo.
React Native lo veremos pronto.
Algo de Machine Learning con JavaScript.
Vale, me lo apunto.
Conseguirte un match en Tinder, amigo mío, eso ya es cosa tuya.
JS Doc te puedes olvidar de TypeScript.
JS Doc me gusta también.
Lo que pasa es que JS Doc no es tan, tan, tan potente como TypeScript.
Todavía tiene algunas limitaciones.
Lo sé porque yo utilizo bastante JS Doc.
Y sí es verdad que es compatible gran parte con TypeScript.
Por ejemplo, para tipos así muy básicos y tal.
Pero con clases y tal se queda corto.
Pero no me desagrada utilizar JS Doc.
De hecho, yo soy un amante de intentar mantener JavaScript porque justamente es lo que va a durar en los tiempos.
O sea, por eso digo que tengáis cuidado de meter TypeScript porque al final si todo vuestro código está en TypeScript está en un lenguaje que no es ningún estándar.
Y bueno, tiene subventajas pero eso es una desventaja.
Sobre todo porque de repente vuestro código está en un lenguaje versionado.
Y eso es lo que realmente es bastante peligroso.
Vale.
En cambio, en JavaScript, ¿cuáles son los casos donde usarías el punto y coma?
No lo usaría ninguno.
No uso punto y coma en JavaScript.
No lo uso nunca.
He visto que muchos usan Flow.
¿Qué opino de Flow?
Opino que no lo aprendáis.
No vale la pena.
Flow, para el que no lo conozca, es la era.
Yo creo que era.
Si no está deprecado, si no está deprecado, lo estará pronto.
Es de Facebook.
Flow es como un TypeScript, pero de...
Vale, no está deprecado.
Vale, todavía no.
Flow es el TypeScript de Facebook.
Pero hay algunos proyectos clave de la propia Facebook que han dejado de utilizar Flow.
Entre ellos creo que React.js.
React.js, si no me equivoco, ha dejado de utilizar Flow.
Así que...
Y ha pasado a utilizar TypeScript.
No sé.
No le veo un futuro muy...
O igual están intentando tener los dos o lo que sea.
Pero ya os digo que no le veo tanto movimiento como le veo a TypeScript.
Así que yo me enfocaría en TypeScript totalmente.
Vale, vamos a seguir.
Vamos a seguir, ¿vale?
Vamos a seguir con tipos AnyUnknown.
Aserción de tipos.
Esto lo hemos visto.
Esto del TypeOf lo hemos visto.
¿Para qué sirve?
Restricciones de tipos.
Mira, estos son los TypeOf que deberíamos hacer justamente para evitar el tema de hacer esta aserción de tipos.
Cuando haces un if TypeOf y le dices este TypeOf, que esto es de JavaScript, ¿eh?
El TypeOf de este...
Cuando el tipo de esta variable es string, entonces ejecuta esto.
Esto lo puedes hacer con los string, con los números, los booleanos, undefined, function y array.
Aunque con array, veis que no es con un TypeOf, sino que es utilizando array, isArray.
Importante.
O sea, aquí, por ejemplo, podríamos hacer if arraysArray randomValue.
Entonces, randomValue te debería dejar acceder a la posición 2.
Si esto lo ponemos aquí, no me deja.
¿Vale? ¿Ves?
Pues, solo cuando una vez has hecho la comprobación de que es un array.
Me parece muy bien que hayan hecho esta comprobación del array.
Porque esto no es con TypeOf, pero bueno.
Siguiente unidad.
Vamos.
Tipos de unión e intersección en TypeScript.
Lleva una hora y dieciocho.
Tenéis en el comando ¿qué haces?
O Uptime.
Uptime y te lo dice.
Tipos de unión e intersección en TypeScript.
TypeScript proporciona opciones más avanzadas para declarar tipos.
Eso me gusta.
Claro, porque hay veces que una variable puede ser de un tipo o de otro.
Así que, ¿cómo sea de eso?
Esto puede ser útil cuando no te has controlado un valor.
La entrada de un usuario, una API, biblioteca.
El tipo any, claro, está bien porque acepta diferentes tipos, pero hay veces que quieres limitar.
No quieres el any, que son todos.
O el unknown, que dices no lo sé.
A veces puede ser que sepas que puede ser uno u otro.
Así que, ¿para qué sería el tipo unión?
Bueno, pues justamente para esto.
El tipo unión se utiliza con la barra vertical y lo que te permite es indicar más de un tipo que puede tener una variable.
Por ejemplo, vamos a quitar los random values que habíamos hecho aquí.
Vamos a poner un multi-type y vamos a decir que esto es el 20.
Pues aquí lo que le podemos decir es que esto es un number o un string.
Le podemos decir, vale, esto es un number o un string.
Así que el multi-type, ahora si le asigno 20, de esta forma, no se queja.
En cambio, si le ponemos aquí type, le ponemos que esto es un number con el 20 y luego el type es 20, aquí sé que se quejaría.
Esto sería el tipo de unión, que puede ser más de una.
Claro, si le dices que es number o boolean, puedes decir que sea un number, un boolean, pero no puedes decirle que es un string, porque tú le estás acotando.
Esto mismo lo puedes hacer también, otra vez, entiendo, con los typeof.
Con las restricciones de tipos puedes trabajar fácilmente con una variable de tipo unión.
Pero claro, como esto puede ser, amigo, como multi-type, puede ser number o puede ser string, ¿qué pasa si yo hago multi-type punto tu uppercase?
Claro, porque si es number, puede ser number o string, no siempre podrá acceder a los métodos del string.
De hecho, si quito esto, ¿qué pasa?
Claro, detecta que lo último que he puesto es un string y entonces sí que me permite.
Pero si le quito el string, me dice, ah, no, amigo, es que tu uppercase no existe en el tipo number, porque sabe que ahora la última vez es number.
Claro, eso puede estar bien en este tipo de variables, pero entiendo que, como puedo ver aquí, ves que tenemos una función, no sé qué, y aquí hace un montón de typeof.
Claro, vamos a hacerlo con una función, function at, y que tenga la x y la y.
Y la x, vamos a decir que es un número, pero que la y puede ser un number o un string.
Entonces, si haces x más y, ya me dice que el operador más no puede ser aplicado a los tipos número y string y número.
O sea, esto es raro, ¿no?
Porque justamente el operador más funcionaría sin ningún problema con números y strings.
Pero, claro, aquí TypeScript, esta magia no le está gustando.
Está como diciendo, ostras, pero es que aquí me vas a liar, me vas a liar.
Claro, entonces por ello, bueno, entiendo que además si pongo aquí que esto puede ser también un string, ya se va a volver más loco todavía.
El operador más no puede ser aplicado a los tipos de string number y string number, ¿vale?
Esto es que el parámetro x es un número o un string y el y es un número o un string.
Entonces, esto es lo mismo de antes.
Si el typeof de num de x es number y el typeof type of y es number, entonces x más y.
Esto sí que funciona.
Porque aquí se está asegurando que esta línea de código solo funciona cuando es de tipo number, la x y la y.
Pero, claro, es un poco raro.
A ver, un poco raro.
Lo que te está haciendo es que seas un poco más cuidadoso a la hora de trabajar con este tipo de datos.
O sea, si le dices que es string, normalmente podrías hacer esto.
Y esto funciona bien.
¿Veis que?
Fíjate que el código es el mismo que teníamos antes.
Solo que ahora la comprobación sabe ahora con seguridad que aquí va a devolver un número y aquí va a devolver un string.
En su ejemplo tiene este, el concat.
Que el concat al final hace exactamente lo mismo.
Y, hombre, queda más legible de que sabes exactamente que es un string.
En lugar de ver el más, que visualmente puede ser un poco más chocante.
Pero te tienes que asegurar, ¿no?
Una vez que tienes estos tipos, bueno, multitipos, es como que tienes que ir haciendo comprobaciones.
¿Vale?
Si es un número puedes hacer esto.
Si es un string puedes hacer esto.
Y eso es básicamente lo que hace.
Claro, si al final lo que puedes hacer es, si tienes estos tipos, haces esto, haces esto y tal.
Y si llegas hasta aquí, pues puedes mandar un error.
You, voy a poner una barra.
You are mixing types.
LOL.
Add 1, 3.
Add 1, 2.
Add 1, 2.
Claro.
Entonces vamos a ver que este devolverá 4.
Este debería devolver 1, 2.
Y este es el error.
Vamos a comprobarlo.
Mmm.
Claro, fíjate, esto es interesante, ¿no?
Fíjate que no me da un error como tal de, oye, los tipos que pones están mal.
Si yo aquí le pongo un true, entonces sí que va a decir, oye, el argumento que me estás pasando no es asignable al parámetro.
Pero claro, esto, esto es correcto.
Esto es un poco lo que decía antes, que tengas, ten en cuenta que, claro, mientras tú le pases los tipos correctos, esto funciona bien, pero luego en tiempo de ejecución tienes que controlar tú los errores.
No te va a hacer TypeScript magia ni nada.
Entonces vamos a ejecutar esto a run.js por aquí y a ver qué pasa.
Vale, ves, me sale el error, no me salen los otros porque no he puesto un console.log.
Pero si hago esto en un console.log deberíamos ver el resto.
A ver.
Pues no, no estoy viendo el...
No sé si es que el error me está rompiendo...
Sí.
Vale, es por eso.
Pero sí, mira, ves, 4, 1, 2 y cuando ejecuto el otro...
Es claro, porque el error sale en otro proceso, ¿sabes?
Tenemos el stdout y tenemos el std error.
Son como dos salidas y entonces no las mezclas.
Cuando vea un error, pues solo te sale la del error.
Vale, pues ya sabemos aquí esto, tipos de unión, intersección.
Vamos con la intersección.
A ver, ¿qué más decir por aquí?
A ver, ¿qué decís?
Nombra las variables y las funciones.
A ver, ¿quién ha canjeado eso?
¿Alguien ha canjeado lo de las variables y las funciones?
Pero creo que no habéis puesto...
¡Fu!
Vale, ahora lo uso.
Vale, a ver, ¿qué me comentáis por aquí?
Se pueden crear tipos de interfaces, lo veremos más adelante.
Type of...
Alguien pregunta si esto funciona.
Sí, el hacer type of x si es igual al type of y, entonces...
A ver, esto funcionar funciona.
Lo que no funciona es que tú esto, al no ser estático, ¿vale?
Esto es dinámico y por lo tanto tienes el mismo problema.
Si tú dices, si el tipo de x es igual que el tipo de y,
pero sabes que el tipo de x puede ser number o string,
pues ves, aquí tienes el mismo problema.
Te dice, oye, el operador más no puede ser aplicado a string o number,
porque como no está diciendo exactamente cuál es,
lo que sí que puedes hacer es guardar, por ejemplo, en una variable,
el type of x en lugar de hacerlo dos veces.
Type of x.
Hay que tener en cuenta que el type of, al final esto lo que te devuelve es un string.
Type of y.
Type of y.
¿Vale?
Entonces, lo que podemos hacer aquí es type of x.
Esto se puede guardar una variable, es number,
y type of y es number.
Entonces, alguien me preguntaba,
perdón, esto, hostia, ahora, así, type of y.
Y alguien me preguntaba, hostia,
ah, mira, fíjate, ni siquiera, ¿eh?
Ni siquiera, ni siquiera, claro, ¿por qué?
¿Por qué no funciona?
Esto es súper interesante.
Porque esto, estamos mezclando código estático, o sea, comprobaciones estáticas,
que es lo que hace TypeScript.
TypeScript no ejecuta nuestro código, no lo ejecuta.
Estamos mezclando una comprobación dinámica,
porque al guardarlo en una constante esto no funciona,
porque TypeScript no es capaz de saber qué tiene el const type of x.
O sea, no lo sabe.
Claro, aquí, si lo ponemos así, sí que es capaz,
porque de forma estática es capaz de leer el código.
Es capaz de decir, ah, vale, o sea, aquí tienes un type of x, ¿vale?
Lo que está mirando es estáticamente el código,
no ejecutándolo para ver lo que tiene.
Así que hay que hacerlo así.
Luego, alguien me preguntaba, ¿por qué los tres iguales?
¿No?
¿Por qué estás utilizando los tres iguales?
Alguien me ha dicho que ponga fu, vamos a poner fu,
que han pagado por la variable, vamos a poner fu.
Vale, entonces, ¿por qué los tres iguales?
A ver, los tres iguales los tendréis que tener más que interiorizados
cuando trabajéis con JavaScript y, por supuesto, con TypeScript,
porque los dos iguales, las comprobaciones que hace,
son bastante más complejas en JavaScript.
O sea, esto, por ejemplo, esto puede darte, ¿ves?
De esta condición siempre devolver a false,
porque los tipos string y número, no, vale.
En el caso de TypeScript, a lo mejor esto, pues, va genial y lo tiene,
que yo no tenía ni idea.
A ver, pues sí.
Qué bueno.
Qué bueno, no sabía que en TypeScript tenía justamente esto,
o sea, que podías utilizar los dos iguales en lugar de los tres.
Pues me parece genial, la verdad.
Supongo que lo comentaré en algún momento.
Pero yo estoy acostumbrado, yo utilizo los tres.
Además, me gusta cómo quedan visualmente,
así que siempre utilizo los tres.
Pero en JavaScript sí que tiene una diferencia bastante importante, ¿vale?
No sé si en el caso de TypeScript lo miraremos más adelante,
a ver si hay algún problema.
Vale.
¿Se puede excluir an en lugar de arroba, arroba?
Pues no lo sé, si se puede, a ver si es que tiene algo.
No, no se puede.
No sé, digo, a ver si TypeScript tiene algo.
Es una pena porque CoffeeScript creo que sí que se podía.
Y queda bastante bien.
No, a ver.
Teníamos...
A ver si salía...
Mira, aquí se podía hacer así.
And.
Pero queda muy, muy verboso.
Muy verboso.
Vale, pues vamos a por más.
Venga, vamos a por más.
Tipo de intersección.
A ver, que esto...
Mira, pero, ostras, aquí ya son interfaces.
Esto es súper raro.
Ostras, nos va a enseñar intersecciones,
pero todavía no hemos visto interfaces.
Bueno, a ver, no pasa nada, pero es súper raro.
Bueno.
Teníamos el tipo de unión, que puede ser uno u otro, ¿no?
Es una O.
Sí, puede ser de un tipo o de otro.
Y luego tendríamos el tipo de intersección,
que se supone que el tipo de intersección
está relacionado con el tipo de unión,
pero se usan de manera diferente,
porque el tipo de intersección combina dos o más tipos
para crear uno que tenga todas las propiedades.
Claro, el tipo de intersección solo tiene...
Bueno, solo no, pero suele tener más sentido
cuando utiliza justamente interfaces.
Una interfaz, que lo veremos más adelante,
es más para identificar cómo es un objeto, ¿no?
¿Qué interfaz tiene?
Puede ser otro tipo de objeto,
no el objeto normal de JavaScript,
pero por ahora piensa eso, ¿no?
Tienes un objeto que tiene unas propiedades
y tú le puedes decir, vale,
este objeto con la propiedad employee,
pues tiene el tipo number.
Con la propiedad age, tiene el tipo number.
Y con esto ya tienes un objeto
que tendrías un contrato de ese objeto.
Vamos a hacerlo.
Vamos a tenerlo así,
y así lo vamos a revisar.
Vamos a quitar todo lo que tenemos por aquí.
Tenemos la interfaz de employee.
Pues podríamos crear ahora en employee,
employee,
que sea del tipo employee,
employee,
y entonces aquí tendríamos que crear ya...
Uy, he puesto un igual.
Estos dos puntos.
Y aquí lo que tendríamos que tener
la propiedad employee ID,
que esto debería ser un número,
y deberíamos tener el age.
Fíjate que tiene autocompletado, por algo.
Y aquí le ponemos el 18.
Si yo ahora, en lugar del employee,
pues esto le pongo que es un string,
hola,
pues esto ya no le gusta, ¿vale?
Porque, ¿ves?
Nos dice, no, este employee ID
yo espero que sea un number.
Esto sería una interfaz.
Me extraña un poco, ¿no?
Cómo es el orden de esto.
Debería ser el orden primero
decirme lo que es una interfaz.
No se me lo he vuelto a saltar, ¿ok?
Creo que no.
Pero bueno.
Entonces, ¿qué pasa con esto?
Que imagínate que en lugar de un employee
yo tengo un...
Una persona, ¿no?
Y esta persona no solo es un employee,
sino que también es manager.
Claro.
Y yo quiero que el employee le diga
que tiene el número de employee,
que tengo la edad, que es 18,
y el stock plan le decimos que es true.
¿Qué pasa?
Que esta persona, si es employee,
pero esta persona es employee y manager,
claro, si solo le digo que es employee,
el problema es que el stock plan
no lo puedo añadir.
Porque me dice, oye,
es que el tipo que estás utilizando
no le puedes asignar justamente
que tenga un stock plan.
Esto no...
En esta interfaz no lo has puesto.
Para eso se utiliza esta forma
que es la de intersección, ¿vale?
La intersección al final lo que te dice
es como un AND,
en la que tiene que tener las dos cosas.
Se tiene que cumplir tanto
que sea employee como que sea manager.
Así que lo que podríamos hacer aquí
es que sea employee y sea manager.
Y ahora esto funcionaría.
Una forma más allá
de reutilizar esta intersección,
porque puede ser que sea muy típica,
no solo que la utilicemos aquí una vez y ya está,
sino que puede ser muy típica,
lo que podemos hacer es crear un type.
Al crear un type le decimos,
vale, tenemos un tipo
que le vamos a llamar employee manager.
Y este tipo es este de aquí.
Es la intersección de employee y manager.
Y ahora este tipo lo podemos reutilizar
tantas veces como queramos.
Y ya tendríamos aquí nuestra persona
y podríamos tener otro aquí.
Y este employee manager,
esta sea la persona B,
que sea 456,
y aquí el 24.
Si le quitas el stock plan,
¿ves?
Pues se queja,
porque dice,
ostras, no,
porque esta persona B me dice
es que es employee manager
y le falta justamente,
aquí nos dice,
está requerido el stock plan.
Te falta.
Vale, pues nada,
le ponemos stock plan
y le decimos que false.
Para eso sería la intersección,
básicamente,
para tener un tipo
que cumpla con dos o más tipos a la vez.
Que tenga todos sus,
de forma conjunta,
el tipo que estás creando
tiene que tener todo en ese mismo.
Ese sería, ¿vale?
Me extraña, de nuevo,
que nos lo enseñen ahora,
pero bueno.
Al final es una forma
de tener un contrato
de cómo debe ser tu objeto.
Porque de esta forma
los objetos que vas a crear
siempre tendrán que estar así
con employee ID y tal.
Si tú intentas crearte
cualquier otra cosa aquí,
por ejemplo Pepito,
pues siempre se va a quejar
y va a decir,
es que no,
esto no funciona.
¿Vale?
Perfecto.
Muy bien.
Pues ahora que ya tenemos
el tipo de intersección,
hemos visto tipo unión,
tipo literales.
Un literal es un subtipo
más concreto
de un tipo colectivo.
Esto significa
Hello World
es un elemento string,
pero un elemento string
no es Hello World
dentro del sistema de tipos.
Fíjate.
Hay tres conjuntos
de tipos literales
disponibles en TypeScript.
String,
Number y Boolean.
Mediante el uso
de tipos literales
puedes especificar
un valor exacto
que debe tener una cadena,
un número
o un valor booleano.
¿Vale?
Entonces,
¿qué es la restricción?
Lateral,
literal.
Cuando se declara una variable
se indica al compilador
que existe la posibilidad
de que esta variable
cambie su contenido.
Pero al usar const
para declarar una variable
informará TypeScript
que este objeto
nunca va a cambiar.
Al declarar con tipos const
la escribes en el valor,
por ejemplo,
Hola Mundo.
Venga,
vamos a ver ejemplos.
Definición de tipos literales.
Vale.
Esto básicamente,
¿qué es lo que quiere decir
todo esto?
Porque la verdad
es que como lo explica
es un poco raro.
Lo que quiere decir
es que tú puedes crear
un tipo
que sea,
por ejemplo,
postAnswer.
Y al tener el tipo este
lo que puedes hacer
con tanto los strings
como los números
y creo que he leído
booleanos también,
aunque es un poco raro,
strings,
number y bolean.
Vale.
Pues al final lo que puedes hacer
es decirle,
vale,
postAnswer,
esto puede ser yes,
esto puede ser no
y esto puede ser maybe
y esto puede ser
follow me to death,
por ejemplo,
¿no?
Entonces lo que estamos
haciendo aquí
es restringir
el string
que puedes utilizar aquí,
¿no?
O sea,
no puedes utilizar
todos los strings
sino que tiene que ser
uno de estos cuatro.
Hay una restricción aquí.
Es algo parecido
a los enums
pero no exactamente
lo mismo,
¿vale?
Pero esto sería
una restricción
de qué strings
son los que puedes utilizar.
Así que ahora
ya puedes crear aquí
tu resultado
y decir que el resultado
tiene que ser
de uno de estos
y si yo ahora aquí
pongo Pepito
pues,
¿ves?
Se me queja.
Dice,
oye,
Pepito no puede ser
asignado al tipo
answer
porque tiene que ser
un string
pero sí,
pero tiene que ser
yes,
no,
maybe o tal.
De hecho,
si pongo aquí dos
pues igual,
¿no?
Me va a decir que no
se puede utilizar.
Ahí donde está el tema.
Claro,
lo bueno es que
hasta que tú hagas esto
tú siempre podrás ponerle
aquí yes,
podrás ponerle el no,
le podrás poner el maybe
pero no le podrás poner
el follow pp
porque el follow pp
no está.
Eso sería una restricción.
Esta señal
las restricciones literales.
Esto sería lo mismo
con los números.
Mira,
este ejemplo
es muy,
muy,
muy bueno.
Este ejemplo
es con un dado.
El dado puede ser
el 1,
el 2,
el 3,
el 4,
el 5,
el 6,
pero no puede ser
ninguno de esos.
Si te sale un 7,
o sea,
solo puede ser
dile un al 6.
Si te sale un 7
pues ya no tiene sentido.
El tema de boleano
sí que me,
me choca,
va a ver,
me choca.
El tema es que el boleano
solo puede ser true o false.
O sea,
no tiene mucha otra cosa.
Si tú dices ya
que es de un tipo boleano
pues ya será así.
No entiendo muy bien
para qué harías
una restricción
de ese estilo.
Pero bueno,
también se puede,
claro.
Me parece interesante.
Vale.
Tipos de colección
en TypeScript.
Venga,
pues paso
y os leo.
¿Cómo estáis?
F por los lenguajes
que no me permiten.
Ya que es.
Si quieres añadir métodos
puedes crear una interfaz
nueva y extender
de la que necesites.
Lo mismo
hay boleanos
cuánticos,
¿no?
Que son true y false
a la vez.
Eso sería genial.
Qué grande.
Bueno,
veo que estáis ahí
charlando
y genial,
¿eh?
Zagiel comentaba
que además lo ha destacado.
Zagiel,
venga,
vamos a ver tu preguntita.
Zagiel,
preguntaba si esto se podía.
¿Vale?
Esto no se puede.
¿Vale?
No se podría.
No se podría
porque esto es el...
Aunque...
A ver,
es que has puesto
unos tipos aquí.
Esto es Type of X.
Yo creo que esto
no se podría.
Porque al final,
aunque es verdad
que tienes estos...
Me lo has puesto difícil,
¿eh?
Zagiel,
me lo has puesto
que es que has...
De alguna forma
has evitado
las letras buenas.
O sea,
tú has puesto
en el teclado esto
y has dicho
voy a ir...
Estoy evitando
las letras buenas.
Ya te digo
que yo creo
que esto
tiene un poco
el mismo problema
que hemos visto antes.
Porque al final,
de alguna forma,
le estamos dando
algo de dinamismo
a esto, ¿no?
Bueno, mira,
aquí parece ser que...
Vamos a ver si...
X más Y.
Bueno, pues parece que sí.
Parece que sí.
Porque en este caso
sí que nos estamos asegurando
que tiene el tipo X
sí que es un Steam.
O sea,
que funcionar sí que funciona.
No sé hasta qué punto
esto tiene mucha historia,
¿vale?
Pero funcionar funciona.
O parece que funciona.
No sé si ponemos aquí o no.
Sí, sí.
Parece que funcionar funciona.
Pues mira,
ahí tienes tu respuesta.
Que funciona.
¿Vale?
¿Saguiel?
Bueno, me alegro
que te hayas reído.
Pero es que, claro,
es que, macho,
me lo has dejado todo
con las mayúsculas mal.
Con todo mal.
Ay, sí.
Igual te escuchamos
a Pepe y a Pepito
siempre nos discriminamos.
Pues mira,
parece que funciona.
Ahí está el tema.
Vale,
vamos a quitar
este playground.
Vamos a volver.
Vamos a dejarlo limpito.
¿Cómo estáis?
¿Cómo os encontráis?
¿Os está gustando?
¿Os gusta el ritmo?
¿Voy muy rápido?
¿Voy muy lento?
Comentadme.
¿Cómo va eso?
¿Cómo va eso?
Rápido, lento,
más caña.
Me encanta.
Samu Garrón le encanta.
Lo digo porque
si os gusta este formato
igual me animo
a hacer muchas cosas más así.
¿Veremos algo
de pruebas unitarias
en TypeScript?
Seguro.
Pero no tiene mucha historia,
¿no, Jean Carlos?
Una prueba unitaria
en TypeScript
al final no debería ser
diferente
cómo las hacemos.
Pero, bueno,
podremos hacer.
Lo miraremos.
Seguiremos con el curso
de TypeScript
y en algún momento
a lo mejor
mandan ejercicios y tal,
pues lo haremos.
Impecable toda la explicación.
Bueno, Nuri,
en este caso,
aunque te agradezco
un montón el comentario,
tengo que decir
que yo en realidad
lo voy leyendo,
pero te agradezco
un montón
el comentario.
¿Tienes el link
del curso?
De este curso,
creo,
si alguien se lo puede pasar,
que ahora,
es que creo que no tengo el,
bueno,
sí,
sí que lo tengo aquí.
Lo paso en el chat
one more time,
¿vale?
Es totalmente gratis,
es de Microsoft,
está bien,
pero bueno,
hay cosas que a mí
al menos me chirrían
que ya las comento
un poco
para que lo vayáis viendo.
¿Usando interfaces
puedo colocar
propiedades privadas?
Sí que puedes,
sí que puedes
y lo,
supongo que lo veremos.
Nada como repasar temas
con gente que sabe.
Gracias, hombre.
¿Cuántos proyectos
profesionales
en TypeScript
has hecho?
¿Dos?
Muy pocos,
no tengo mucha experiencia
con TypeScript,
por eso también
quiero hacer el curso.
¿Vas a combinar
TypeScript con React?
Hoy no,
pero seguro que
más adelante, seguro.
¿Algo de comportamiento
de usuarios
con Segment Analytics?
Ostras, pues,
mira,
eso es interesante,
¿verdad?
¿Qué es?
Me gustaría hacerlo
más adelante.
¿Se puede heredar
interfaz?
Se puede.
Y es parte de la gracia
de hacer esto.
Las interfaces
no tienen
propiedades privadas.
Vaya,
Pumuki y Cósmico
nos ha fastidiado
el tema.
Pensaba que
sí que había.
Sí que había,
o sea,
propiedad privada.
Claro,
al final entiendo
que lo que tienes que hacer
es implementar
una interfaz,
¿no?
Y la interfaz
entonces le dices
a la clase
le dirías
lo que es privada
y tal.
Tiene sentido.
Pero sí,
pensaba que
se podría hacer
ningún problema.
Pero bueno,
pues ya sabemos que no.
Gracias,
Pumuki.
Son las clases.
La playlist de TypeScript
en YouTube
todavía no...
Este es el primer vídeo.
Este es el primer vídeo,
así que todavía no hay.
Vale,
pues venga,
vamos a seguir
que hay historia.
Vamos a ver
si terminamos
las 10 unidades,
¿vale?
Tipos de colección
en TypeScript.
Los tipos de objetos
son todos los tipos
de clase,
de interfaz,
de matriz
y literales.
Todo lo que no sea
un tipo primitivo.
Los tipos primitivos
que hemos visto antes.
String,
bolean,
number,
bla.
Veamos los tipos
de matriz
y de tupla.
Tupla me parece
súper interesante,
pero es verdad
que ahí hay una historia
que luego os comentaré.
Venga,
vamos con matrices.
Bueno,
matrices o arrays,
como me queda llamar.
En este caso
entiendo que por matrices
se puede entender más,
pero arrays,
¿vale?
TypeScript,
al igual que JavaScript,
permite trabajar
con matrices.
Las matrices
se pueden escribir
de dos maneras.
Esto se usa
el tipo de elementos
seguido de corchetes,
o sea,
aquí le estaríamos diciendo
la variable
let list,
el tipo es
un array
de numbers,
¿vale?
La verdad es que
no me gusta mucho
la forma,
se lee como al revés,
es un poco rara.
Es number
y luego array.
Me hubiera gustado más
de otra forma,
pero bueno,
aquí veo otra forma,
pero me ha gustado
una tercera,
que ahora os explicaré.
Igual,
y aquí tendríamos
el array,
ya está.
En el segundo caso
se usa un tipo
array genérico
con la sintaxis
array
y dentro
el type.
No sé,
a ver,
Pumuki,
cósmico,
a ver cuál es el que,
cuál te gusta más,
Pumuki,
ahora que te veo
que eres un crack
de TypeScript
para que sepamos
tu opinión,
tú que sí
que la has utilizado.
A ver,
¿por qué?
¿Por qué os digo esto?
Esta sería una forma,
¿vale?
De indicar
un array de números
y luego tendríamos
esta otra forma,
¿no?
List B.
Pero la verdad
es que a mí
si pudiera elegir
la que me gusta más
sería algo así.
Pero claro,
¿qué pasa con esto?
Que esto en realidad
lo que quiere decir
es que es un array
de un elemento
que tiene un número.
Por eso se queja.
Entonces no sé
si se podría hacer algo así.
Eso ya sería genial,
pero entiendo que no.
Arrest Element Type
must be an Array Type.
Bueno,
estas son mis ensoñaciones.
Nos vamos a tener
que dedicar
a aprendernos esta.
Hombre,
esta creo que se lee
un poquito mejor
en el sentido de que
dejar para el final
lo que debería estar
del principio...
Bueno,
iremos viendo, ¿no?
Iremos viendo.
Vamos a leer,
a ver.
¿Os gusta más la primera?
La primera forma
es la más usada.
Repite la pregunta.
Vaya,
te la has perdido.
Pero ha habido gente ahí
que sí que ha estado
atenta.
Entiendo que la primera
es la más usada,
pero la de abajo
yo creo que la he visto
en más lenguajes, ¿no?
Más allá de TypeScript.
O sea,
igual es más conocida
allá afuera.
Entiendo.
No sé.
Bueno,
las iremos cambiando,
me imagino.
Claro,
las tuplas.
Tener una matriz
de los mismos tipos
de valor es útil.
Claro,
esto es cuando tienes
un array de no sabes
cuántos números
y todos son del mismo tipo.
Pero a veces tienes
una matriz
que contiene valores
de tipo mixto.
Por ejemplo,
un hook de React,
el useState,
pues tienes el primero
que es un valor
y el segundo
que seguro
es un método.
Así que,
TypeScript proporciona
el tipo de tupla.
Para declarar una tupla
se usa la sintaxis,
la que he estado
utilizando justamente antes.
O sea,
tú puedes tener aquí
una personita
y le decimos
que la persona
tiene primero un string
y luego tiene un número.
Y esto,
pues puede ser
que tenga
midudev
y luego,
pues tenga su edad,
que es 18.
La edad de midudev
es 18.
Esto sería,
¿no?
Y si le ponemos aquí
que tiene otro string
pues esto ya peta
porque no estamos
con la tupla
no está funcionando correctamente.
¿Vale?
Perfecto.
Aquí tendríamos
este ejercicio.
A ver,
si intentas agregar
aquí otro elemento
pues también te petará
porque la tupla está mal.
Y lo mismo
si la ponemos aquí.
O sea,
eso lo hemos visto.
Se genera un error
porque los elementos
de la tupla
son fijos.
Prueba a cambiar
el orden de los elementos
de la raíz.
Por lo mismo,
claro,
si pongo aquí el number
como el primero
pues también me petará
porque midudev
es un string.
¿Ves?
Estos tipos de string
no se asignan
a tipo número y tal.
Bueno,
ya hemos dominado
las tuplas.
Ya está.
Tuplas,
check.
No,
pues parece ser
que ha funcionado bien,
¿no?
Cuando he puesto
la edad
como 18
pues ha funcionado
perfectamente.
O sea que
creo que será verdad.
Venga,
vamos con la siguiente.
Uso de tipos
en TypeScript.
En este laboratorio
escribirá el código
de JavaScript
en cada uno
de los ejercicios
siguientes en TypeScript
tipando fuertemente,
fuertemente,
con fuerza,
cada una de las variables.
Modificación del código
de JavaScript existente
para que tenga variables
fuertemente tipadas.
A ver,
no sé si clonármelo directamente.
Ostras,
ostras,
madre,
venga,
vamos a clonarlo,
va.
Vamos a clonarlo.
Clonamos el ejercicio,
vamos a
Ems Learn,
TypeScript,
Module,
Module,
Module,
pues esto empieza mal.
Ah,
Code,
esto está mal,
esto está mal.
Está mal.
CD,
a ver,
me está engañando esto.
Ah,
vale,
vale,
vale,
no,
no está mal,
soy yo que me lo podía haber copiado
directamente
y ya está.
Vale,
M02,
Start,
que es donde va a estar
nuestro código de inicio.
Vale,
y ahora nuestro Module
ya veo aquí un montón de problemas,
de hecho,
esto,
esto es tener mala baba,
vale,
esto es tener mala baba.
Vamos a ver,
este First Name
está mal escrito,
esto es con Camel Case,
o sea,
empieza mal la cosa,
eh.
Vale,
lo demás,
más o menos.
Eso es,
¿Random Numbers
está usada antes de qué?
Antes de ser asignada.
Ciertamente.
Vale.
Ejercicio 1.
Modifica el código
para añadir tipos
a la declaración de variables.
El código resultante de JavaScript
debería ser igual
que el ejemplo original
que has hecho.
No sé qué decir
ejemplo original que he hecho,
pero First Name
es un string,
esto es un string,
el Full Name
es otro string,
el Age
es un Number
y el UK Citizen
es un...
es un Brexit.
No,
es un bolean.
Hasta aquí,
bien, ¿no?
Vale,
My Name
es no sé qué,
no sé cuánto,
bueno,
pues hasta aquí
ya está,
ya está,
fantástico.
Creo que eso está bien.
Ejercicio 2.
Puedes usar tipos
para asegurarte
cómo termina
la operación.
Ejecuta este código
como está
y entonces modifica
para que tenga
variables tipadas
fuertemente.
Entonces,
arregla cualquier error
que tengas
hasta que el resultado
sea 12.
Vale,
vamos a recuperar esto,
lo voy a poner aquí,
a ver qué pasa con esto.
Vale,
¿qué está pasando aquí?
Que la X
es 5,
esto es 7
y esto me da 5, 7.
Pero claro,
a ver,
esto es un poco trampa,
¿no?
Porque dice
ejecuta este código
y entonces modifícalo.
Bueno,
pero es que,
a ver,
vale,
primero deberíamos poner
que esto es un number,
¿no?
Entonces ya me quejaría
y me diría,
oye,
no,
es que aquí tienes un string,
¿qué haces?
No,
perdona,
es que soy tonto.
Entonces,
en lugar de escribir el 5
como un string,
lo escribo como un número
y el A,
pues nada,
también sería un number,
¿no?
Y ya está,
este sería ejercicio.
Vale,
¿cómo lo llevo?
Bien, ¿no?
La edad de midudef es 18
y no ha fallado el compilador.
Parecía más grande.
El string es equivalente a 1
si fuese boleano.
¿Cómo?
El string es,
ahí me he perdido.
Samugarrón,
ahí me he perdido.
No sé qué comentas con eso.
Ejercicio 3.
En el código siguiente
implementa un enum.
Vale,
a ver si me acuerdo
cuál es el enum.
Enum,
venga,
enum
llamado season.
Venga.
¿Qué contiene?
Fall,
ahí,
esto era así,
así,
fall,
winter,
spring,
summer,
y winter,
is coming.
Vale,
tenemos season.
Y entonces,
actualiza la función
de forma que,
lo que le pasas,
season,
esto tiene que ser
el tipo season,
vale,
ajá,
month in season,
ahora el problema es,
ahora,
actualiza la función
de forma que le pasas
un season,
referenciando en el item,
el enum,
por ejemplo,
season.fall,
en lugar del literal,
claro,
en lugar de utilizar
el literal así,
ahora lo que tenemos que decir
esto es,
cuando me pasas
season.fall,
tal,
cuando me pasas
season.,
punto,
claro,
es que esto es mucho mejor,
esto es genial,
o sea,
esto es mucho mejor
a la hora de trabajar
con esto,
de hecho,
a ver,
season no sé qué,
vamos a probar una cosa
con esto,
vale,
y esto igual,
season.fall,
vale,
y esto lo deberíamos
poder ejecutar,
y deberíamos ver el código,
september to november,
vale,
perfecto,
una cosa que estaba pensando,
es,
¿se puede,
se puede crear
un diccionario
que sea,
eh,
eh,
eh,
months,
por ejemplo,
y yo aquí utilizo el,
utilizo season.fall,
y aquí le digo que season.fall
es esto,
esto ya es curiosidad mía,
season.winter
es esto,
me imagino que sé que se puede
sin ningún problema,
¿no?
Y entonces,
season.
y aquí está el fall,
vale,
entonces aquí,
hacer un return
de months,
que le pasas el season,
punto,
bueno,
le pasas el season,
y ya está,
¿sí?
Queda bastante mejor,
pues está genial,
¿no?
Está genial,
está bien,
el poder utilizar un enum aquí,
directamente,
está bastante bien,
porque de esta forma,
tienes aquí ya todos los,
el diccionario,
y aquí le pones esto,
y tal.
Me gusta más este código,
que tienen ahí,
pero bueno,
este es ejercicio 3,
para los que me preguntan,
sobre este,
esto es run.js,
y se sirve para ejecutar,
javascript y typescript,
y te ponen la consola,
y tal,
es genial,
es genial.
declaración de un tipo de matriz,
¿vale?
Busque ejercicio 4,
declare la matriz como el tipo que va a coincidir,
con el tipo de elementos de la matriz,
¿vale?
Vamos a nuestro código,
random numbers,
a ver,
random numbers,
random numbers,
vamos a poner que esto es un numbers,
y es un array,
can't find numbers,
¿vale?
Ay, numbers,
yo también,
number,
el next number,
entiendo esto,
es un solo number,
¿vale?
Y aquí pone que random numbers,
además,
claro,
antes de ser inicializado,
es que esto debería ser un array vacío,
¿no?
Al principio,
y esto,
next number,
esto es un número,
le hacemos el push,
vale,
vamos a ver si esto funciona,
pam, pam, pam,
perfecto,
muy bien,
muy bien,
hemos terminado nuestros ejercicios,
así que,
vamos al siguiente,
que es comprobación de conocimientos,
vamos a ver,
comprobación de conocimientos,
espero no fallar,
madre mía,
qué miedo,
a ver,
nervios,
nervios,
agüita,
¿qué acabo de hacer?
¿qué ha pasado?
¿qué he hecho?
Sí,
RAM Venezuela,
estoy aprendiendo TypeScript,
y lo estoy haciendo aquí,
en sociedad,
en comunidad,
¿qué he hecho?
Vi parcero,
y Hakon dice que también
prefiero evitar los switch
usando diccionarios,
ahí está,
¿de qué categoría
de subtipo de any
son ejemplos
los tipos bolean,
number,
string,
y en un?
Son tipos primitivos,
sin copiar,
¿eh?
No he copiado,
he hecho nada,
no hay chuleta,
no hay chuleta,
¿cuál de los siguientes tipos
es un ejemplo
de tipo objeto?
¿el array?
¿el array no?
Yo creo que sí,
hostia,
o parámetros de tipo,
bueno,
yo creo que es el array,
bueno,
ahora veremos,
¿qué más?
¿cuál es la diferencia
principal
entre los tipos
any
y unknown?
¿cuál es la diferencia?
Puedes asignar
cualquier valor
a un known
pero el tipo any
tiene algunas restricciones,
mentira,
puede acceder
a las propiedades
de un tipo unknown
pero a un tipo any,
mentira,
puedes acceder
a las propiedades
de un tipo any
pero no a un tipo unknown,
eso,
¿cuál es el nombre
de la característica
en typescript
que indica el compilador?
¿sé lo que estoy haciendo?
Me encanta esa,
sé lo que estoy haciendo,
aserción de tipos,
ahí está,
¿qué es una tupla?
¿una matriz
con un número infinito
de elementos
del mismo tipo?
Mentira,
¿una matriz
con un número específico
de elementos
del mismo tipo?
Mentira,
¿una matriz
con un número específico
de elementos
de uno o más tipos?
Venga,
¡bravo!
Ya tenemos
400 puntos de experiencia más,
no sé para qué sirven
estos puntos de experiencia,
no sé si voy a poder
evolucionar como Pikachu
pero bueno,
ya está bien.
Ahora que he revisado
el módulo,
ahora soy capaz
de explicar las ventajas
de declarar variables
tipadas en typescript,
espero haberlas explicado bien,
declarar variables
mediante tipos primitivos,
declarar variables
mediante tipos de objetos,
bla, bla, bla, bla,
y aquí un montón de recursos,
desbloquear el logro,
dame mi logro,
dámelo.
Implementación de interfaces,
muy bien,
qué bonito,
continuar.
Os paso,
os paso el link,
os paso el link.
¿Vale?
¿Por dónde vamos ya?
Vamos ya para el...
Vamos por la mitad,
casi creo,
¿no?
Hemos hecho introducción,
declaración de tipos de variables,
te lo hemos terminado,
implementación de interfaces,
es el que nos queda ahora.
Vale.
Implementación de interfaces,
bueno,
esto lo dejaremos ya
para la semana que viene.
¿Os ha gustado el formato o qué?
¿Os ha gustado?
¿Os ha gustado así?
¿Cómo estáis?
A ver,
la semana que viene
seguiremos,
me imagino,
con este,
para continuar con TypeScript,
porque, bueno,
lo quiero aprender,
lo voy a necesitar en mi trabajo
y hacía como 5,
4 o 5 años
que utilicé TypeScript,
o sea,
hace un montón de tiempo
y, claro,
ha cambiado bastante,
entonces,
ya casi no me acuerdo de mucho
y lo tengo que refrescar.
Y sé que han salido
como 2 o 3 mayos,
o sea,
que cuanto antes,
pues mejor.
Así que vamos ahora
con unas preguntas.
Andrés,
¿qué PC recomiendas
para programar
que no sea tan costosa?
Define tan costosa.
¿Cuánto es tan costosa?
¿Nos explica
lo que hiciste
con los diccionarios?
No lo entendí.
Claro que sí,
mi parcero,
te lo explico.
Muy chulo el formato,
gracias Alberto.
Muy bueno el formato,
voy a ver si me pongo
a hacer el curso.
Gracias, Ariel.
Te explico lo del diccionario,
a ver.
No sé dónde lo he hecho,
pero en algún sitio
que lo he hecho,
te lo explico.
Voy a tirar para atrás.
Vale.
A ver,
esto en realidad,
no sé cómo se llama esto,
esto tiene un nombre,
¿vale?
Yo lo llamo diccionario,
pero esto tiene un nombre.
Al final,
voy a copiarme esto aquí.
Esto que he hecho aquí,
imagina que tú tienes un switch,
¿no?
Tienes un switch case,
un switch,
y en el switch,
tú lo que le dices,
cuando tengo season,
en el caso de que tenga season fall,
entonces tengo month in season tal,
¿vale?
Entonces,
si te fijas aquí,
esto de alguna forma,
lo que estás haciendo es que,
cuando tienes esta key,
entonces tienes este valor,
¿vale?
O sea,
ya ves aquí la referencia key value,
key value,
¿vale?
O sea,
ya estás viendo aquí
que hay un patrón,
¿no?
Que cuando tienes esto,
entonces lo otro.
Entonces,
ya estás viendo que hay este patrón
que puedes extraer,
de forma que tú creas un diccionario,
le llamamos dictionary,
¿vale?
Aunque tiene más sentido
season months,
season months,
de forma que la key,
que es lo que tendríamos aquí,
aquí le puedes poner la key que sea,
puedes poner pepito,
y pepito,
pues que esto sea dos,
¿vale?
Pero,
en nuestro caso,
no queremos que sea pepito,
queremos que sea cuando tiene el valor season fall,
que season fall,
ya sabemos,
por lo que hemos visto en el curso,
que esto es cero,
esto es uno,
esto es dos,
y esto es tres.
Una cosa que podríamos hacer es,
cuando es cero,
entonces,
tenemos este valor de aquí,
¿vale?
Cuando es uno,
tenemos este valor de aquí.
Esto del cero y el uno y tal,
no me lo estoy inventando,
sino que sabemos que cuando haces un enum,
empieza por el cero,
y va aumentando,
cero,
un,
dos,
tres,
¿no?
Y aquí lo haces.
Pero claro,
esto hace que sea difícil de leer.
¿Por qué?
Porque yo ahora,
cuando veo aquí visualmente el cero,
el uno,
el dos,
pues no me entero.
Digo,
ostras,
el cero,
uno,
el dos,
¿esto qué es?
¿Esto es números?
¿A qué se refiere esto,
no?
Entonces,
en los objetos,
tú puedes utilizar como key una variable.
En este caso vamos a utilizar las variables de los enums.
Vamos a utilizar el season.fall.
Y esto,
este season.fall,
si ponemos aquí un console.log,
season.fall,
esto nos va a devolver cero.
Por lo tanto,
esto y esto,
september to november,
estas dos líneas hacen lo mismo.
Hacen lo mismo,
solo que de una forma,
la primera mucho mejor.
¿Por qué?
Porque si el día de mañana,
el season.fall,
hacemos que empiecen por 25,
este código funciona correctamente
y el otro,
este cohes con números,
no funcionaría.
Así que,
lo mejor sería utilizar las keys,
que además visualmente te ayuda a entender mucho mejor el código.
¿Vale?
De esta forma te puedes,
te puedes eliminar el switch,
porque el switch,
si te fijas al final es como un if else,
if else,
en lo que lo único que importa es el key y luego el value.
Entonces,
si,
dependiendo de que el season sea,
season.fall,
te da este valor,
al final lo que puedes hacer es tener este diccionario de aquí
y extraer justamente en el months in season este,
decirle,
es que ni siquiera necesitas,
lo mejor de esto es que ni siquiera necesitas la variable,
pero bueno,
al final lo que puedes hacer es extraer
months in season,
es del tipo string,
y esto me lo encuentras en este diccionario season month,
accediendo a la season que me pases.
Esta season que me pasas,
que es del tipo season,
que será una de estos,
la fall, winter, spring y tal,
vienes al diccionario y devuelve este string,
y esto,
pues ya lo puedes devolver y quedarte muy a gusto,
lo devuelves y te quitas todo este código,
que es horrible,
y ya está.
Esto tiene mil millones de ventajas,
o sea,
no solo queda mucho más claro el código,
no solo además extraes esta funcionalidad de forma que esto lo puedes exportar y lo puedes reutilizar más adelante,
en lugar de estar dentro de la función,
normalmente los switch case no son tan reutilizables ni fáciles de comprender,
y además están dentro de la función, de la ejecución de la función.
Esto lo que te permite es extraerlo mucho más fácil.
Y además de esto,
bueno,
es que esto lo podríamos simplificar,
porque esto puede ser directamente,
esto al final,
esto ya es un reto,
es que ni siquiera,
o sea,
esto ni siquiera ya necesita hacerlo así.
Y con esto ya lo tendrías.
Y bueno,
podríamos seguir,
podríamos seguir,
haciéndolo más cortito.
Y así,
y ya estaría.
Bueno,
¿ahora qué le ha pasado esto?
No le ha gustado.
Bueno,
no sé por qué no le ha gustado,
pero,
ah,
vale,
por los tipos,
claro,
por los tipos,
porque los tipos así no nos están entendiendo bien.
Pero bueno,
que ya pillan la idea,
que se podría simplificar.
Esta sería un poco la idea.
Esta sería un poco la idea.
A ver,
¿qué me decís en el chat?
Obtained,
eso,
computed property names.
Siempre se me olvida hasta acá.
Gracias por el nombre.
Ese es el nombre,
correcto.
Tablas de hash,
también puede ser el nombre.
Pepito va a acabar pidiendo el copyright,
que venga a buscarlo.
También existen los new map en más scripts.
Es verdad,
lo de los map,
se podría utilizar un map aquí.
Pero,
el tema de los map,
en este caso,
yo no le encuentro tanto valor.
¿Vale?
¿Por qué no le encuentro valor?
Uno,
porque normalmente no está soportado por todos los navegadores de la misma forma que sí que lo están los objetos.
Dos,
porque a mí me resulta incluso mejor visualmente esto que en un map,
porque el map al final lo que tendrías que hacer sería algo así, ¿no?
New map.
De hecho,
a mí,
si me preguntas,
me gusta más el objeto,
pero bueno,
sería algo así, ¿no?
Haces un set de esto.
Otra cosa,
otra cosa es que el map tiene otras ventajas,
que aquí no estaríamos utilizando.
Si vas a utilizar las ventajas que tiene el map,
entonces sí.
Me refiero en este ejemplo en concreto, ¿eh?
Pero sí,
con el map tendría que ser así.
No me gusta tanto con el map,
porque al final,
aunque sí que es una estructura,
la tienes que construir llamando a métodos y tal.
No sé,
el objeto me parece mucho más elegante en este tipo de construcción,
pero es verdad que el map al final tiene otro tipo de ventajas,
porque es un objeto que es totalmente iterable,
súper fácil,
no sé,
o sea,
tiene sus ventajas,
pero puedes mirar si existe una aquí,
o sea,
la forma de buscar es mucho más fácil también,
pero tampoco me parece tener una gran ventaja en este ejemplo,
¿vale?
Enum Season es un array,
enum Season es,
creo que es un objeto,
no tengo claro que sea,
no sé si lo transforma esta en un array o un objeto,
a ver,
a lo mejor es que al final,
¿sabes qué pasa?
Que los arrays y los objetos son lo mismo,
lo que pasa es que un array,
un array al final es un objeto así,
es esto,
es exactamente lo mismo,
entonces,
no desconozco si es exactamente un array o un objeto,
pero al final será cualquiera de los dos que debe ser muy parecido,
¿por qué pones los...?
Claro,
¿por qué pongo esto?
¿por qué pongo esto?
¿no?
Alguien me dice,
¿por qué pones estos corchetes?
A ver,
estos corchetes son necesarios,
porque si tú le pones Season.fall,
esto,
esto es incorrecto sintácticamente,
¿vale?
¿Ves?
Te dice,
mira,
no esperaba este token,
no puedes poner un token,
esto no se puede poner así en un token,
¿vale?
Este,
es que no existe esta forma de escribir.
Además,
si tú pones,
por ejemplo,
si ponemos aquí Season,
entonces ya tendríamos un problema,
imagínate que pudiésemos ponerlo,
claro,
Season,
en realidad es lo mismo que poner el string Season.
Entonces la forma correcta de poder utilizar una variable como propiedad de un objeto
es poniéndole los corchetes,
que si lo piensas fríamente es lo mismo que cuando lo accedes,
¿no?
Que pones los corchetes con la propiedad,
Season.fall.
Así que tiene sentido que sean corchetes.
Si no,
no entiende que lo que quieres hacer es evaluar una variable,
por eso tienes que utilizar los corchetes.
Vale.
Eso me preguntó Chris con Roo.
Qué buena esa forma de hacerlo.
Para usar valores dinámicos,
porque se usa el enum,
se puede usar funciones flecha,
se puede,
o sea,
que puedes usar adicionales para cambiar el switch en los reducers de Redux,
totalmente.
De hecho,
esto que hemos hecho aquí,
este Season Month,
esto también puede ser incluso interesante para tener funciones.
Tú esto,
haces que sean funciones,
claro,
es que ya os digo que esto tiene un montón de utilidades.
Puedes hacer que esto sean funciones,
imagínate que aquí le pones prefix,
y entonces aquí ejecutas el prefix,
algo así,
y entonces ya tienes el prefix,
que lo puedes utilizar,
con un valor por defecto,
o sea,
va mucho más allá este pedazo de patrón.
Es súper interesante este patrón,
y creo que es uno que hay que dominar un montón.
Con los enums,
al final se tipean menos teclas,
los objetos no serían iterables,
creo,
en comparación con los arrays.
Los enums,
al final,
se tipean menos teclas,
claro,
lo interesante de los enums,
es que puedes acceder así,
directamente,
es súper fácil.
Con los objetos,
es un poco más,
hostia,
no sé qué ha pasado ahí,
pero,
eso es el enum,
vale,
pues mira,
es una variable,
es una función que se auto ejecuta,
que al final,
por lo que veo,
es un objeto,
o sea,
es un objeto,
tal cual.
¿Conoces Overmine JS?
No lo conozco,
Overmine JS,
no sé qué es.
Mira,
lo he abierto por aquí.
Overmine JS,
dice que es,
bueno,
no dice lo que es,
es Frictionless State Management.
Ahora que lo veo,
me suena,
ahora que lo veo,
me empieza a sonar un poco más.
Vale,
separar la lógica,
me parece bien.
Acciones.
Esto de separar la lógica,
me parece muy bien.
Bueno,
al final,
es una forma de tratar el estado.
Bueno,
me parece interesante.
No lo conocía al final.
State Management,
hay tantos y tantos.
Ah,
mira,
tiene DevTools.
Esto parece bastante bien.
Esto,
esto parece como,
como GraphQL,
no sé,
se me parece.
Pues no lo conocía.
Gracias por compartir.
Igual le he hecho un vistazo
en algún momento.
En tu ejemplo,
dice Nuri,
Season sería un type custom.
A ver,
en mi ejemplo,
cuál sería,
bueno,
a ver,
es que ahora,
este SeasonMonth,
aquí lo he duplicado,
he puesto un montón de cosas.
Sería,
cuál sería custom,
porque aquí no veo que,
que haya ningún custom.
¿No?
SeasonMonth,
estamos accediendo aquí.
Bueno,
aquí,
claro,
no le he puesto un tipo,
claro,
no le he puesto un tipo.
el tipo que entiendo que debería,
no hemos visto
qué tipos,
cómo se hacen,
supongo lo vemos en la siguiente clase,
pero lo que deberíamos hacer aquí
es que fuese un objeto,
que esto fuese de un String
y esto que fuese un String.
Creo que esto es como deberían ir los tiros.
¿No?
O sea,
lo que nos gustaría,
a ver,
voy a quitar esto,
es algo así,
que lo podríamos hacer de otra forma.
o sea,
que esto sería el Season,
ah,
bueno,
esto no es un String,
es un Number,
perdón,
esto sea un nombre,
SeasonId,
o como lo queráis llamar,
y sería algo así,
¿no?
O sea,
un objeto que tiene,
pero sí,
o sea,
todavía no hemos puesto aquí
ningún tipo de,
tenemos que hacerle una interfaz
o lo que sea.
Exacto.
Tarscript también admite
desestructuración,
whichMonth SeasonTal.
Bueno,
en este caso,
este caso,
esto en realidad
lo que hace es devolver
un String,
¿no?
Esto ya,
el whichMonth,
esto ya lo que hace
es devolver un String,
que creo que es por aquí,
si no me equivoco.
Esto ya sería un String,
y ya está.
¿Se puede iterar
un en un?
Me imagino que sí,
que no debería haber
ningún problema.
A ver,
seguro que sí.
Seguro que sí,
porque al final,
a ver,
se puede hacer,
seguro con un forOf,
hagámoslo en un momento.
A ver,
forLet Season
in Season,
bueno,
Seasons,
no sé si esto
no dará algún problema,
pero,
console.log Season.
Ahí lo tienes.
Bueno,
la cosa que nos da,
0,
1,
2,
3,
4,
Season in Season.
nos está hidratando
de más.
Nos está dando aquí
demasiadas cosas.
No nos está dando
lo que realmente queremos.
Vamos a ver.
Pero a ver,
se tiene que poder,
seguro.
Season,
Season,
Fall,
Winter.
Ostras,
es que tiene aquí
las dos cosas.
Qué curioso,
¿eh?
Claro,
tiene por un lado,
esto es muy interesante,
claro,
necesita como el diccionario
hacia los dos lados.
Esto está muy bien.
Bueno,
lo que podrías hacer,
por ejemplo,
para iterar lo fácil,
a ver,
esto es una cosa
que se me ocurre a mí,
pero una cosa
que puedes hacer
es que,
si es none,
el number
del Season,
entonces hace
el Console Log.
No creo que sea
la mejor forma,
pero vaya,
así seguro
que lo puedes iterar.
Si no es un número,
pues lo haces
y ya está,
ya lo tendrías.
Ay,
perdón,
que no estáis viendo.
Perdón,
perdón,
perdón,
perdón,
perdón.
Bueno,
básicamente,
lo que he hecho,
entonces,
eres muy guapo,
pero no vemos el código.
Hostia,
es verdad.
Tengo que hacer
alguna cosa
para que cuando,
¿sabéis que si os suscribís
con Prime,
suena la campanita?
Vale,
pues así,
lo podéis hacer.
Ahora,
ahora sí,
ahora sí,
perdón.
Vale,
lo que estaba haciendo
es un For Let Season
In Season,
¿no?
Y entonces,
el problema
que estaba viendo aquí,
de lo que estaba comentando
cuando estabais ahí,
es esto,
que están todos los 0,
el 1,
el 2,
el 3,
porque tiene el diccionario
hacia los dos lados.
O sea,
hacemos un Console Log del Season,
vemos que tiene el diccionario
1 con los números,
0,
1,
2,
3,
y te dice la key
del enum,
y luego tenerla aquí
y el enum
con el valor que tiene.
O sea,
tiene el diccionario
hacia los dos lados,
que tiene todo el sentido del mundo.
Entonces,
la forma rupestre
que se me ocurrió
de que podríamos hacer esto,
porque en un object keys
al final va a pasar
un poco lo mismo,
sería hacer esto.
si es NAN,
si intenta transformar en NAN,
o sea,
si cuando transformas
en NUMBERAL Season
es NAN,
pues nada,
entonces lo enseñas
y ya está.
No me parece que sea
la mejor,
pero bueno,
puede ser una de ellas.
Ya me extraña,
la verdad es que me extraña
que,
no sé,
entiendo que a lo mejor
que el object keys
sí que lo hace.
No lo he probado,
lo he ido a saco,
pero a lo mejor,
ves,
no,
el object keys también salen,
claro,
tiene sentido,
tiene sentido,
porque claro,
y el object values
al final sería lo mismo,
si haces object values
pues sería al revés,
vaya,
ves,
for winter,
no sé qué,
no sé cuánto,
igual esta podría ser una,
porque entiendo que
solo son los números,
podría ser,
pero no sé si está pensado
mucho para iterarlo,
de esta forma,
o sea,
yo creo que los enum
no están pensados
para que sean iterables,
sino que en realidad
están pensados
para que sean como
enumeramientos,
o sea,
para enumerar cosas
del palo
como los días de la semana,
no es tanto como
que los vayas a iterar,
sino que es más
que los vas a utilizar
directamente,
de cuando quieres
referirte a un día
y cosas así,
no,
object entries
es lo mismo,
sería más o menos
el mismo problema,
object entries,
pues que vamos a tener
cero,
está repetido,
básicamente,
a ver,
otra cosa que se puede hacer
es recuperar
de la mitad
para la ante,
cosas así,
pero bueno,
no creo que sea la forma,
bueno amigos y amigas,
muchas gracias
por estar aquí,
espero que
os lo hayáis pasado
tan bien como yo,
nos vemos este domingo
con el Full Staff Bootcamp,
que a ver qué tal,
vamos a hacer el Redux,
así que espero
que estéis por aquí,
que lo paséis bien,
que vamos a seguir aprendiendo
y no paramos,
no paramos de aprender
aquí cada día,
una cosa loca,
una cosa loca,
así que nada,
espero que estéis muy bien,
que hayáis aprendido como yo,
sobre todo con temas
de TypeScript
y que ya sabéis
que si os gusta mucho
el canal,
pues que por aquí
estamos de vez en cuando,
que no olvidéis pasaros,
poneros ahí a suscribir,
campanita y lo que sea
y por aquí estaremos,
¿vale?
Así que te mando
un brazo,
un brazo también,
un brazo,
toma un brazo,
un abrazo,
un abrazo enorme
y que pases un muy buen
fin de semana,
que lo disfruten mucho
y gracias por los 50.000
suscriptores en YouTube,
os lo agradezco un montón,
de corazón,
sed buenos,
chao,
chao,
cibo,
barf,
brunia,
exenza,
ospino,
santiu,
y obvi,
exenza otra vez,
zagiel,
pumuki,
cósmico,
que uno de sus grandes,
dice que una de las mejores cosas
que le ha pasado en la vida,
no,
su gran logro de este año
ha sido corregirme,
samu,
garrón,
nuri,
197,
hay 196 nuris también por ahí,
andrés,
tacruz,
cami,
cami maya,
cami,
¿cómo estás?
santio este,
frik,
frik,
soy franz,
hecon,
Andrea,
Yomar21manucho
y con esto nos vamos a cenar,
un ratucho,
hasta luego,
chao.