TypeScript puede inferir el tipo de dato de una variable a pesar de no haberlo declarado explícitamente.
Inferencia de tipos
A partir de la inicialización de la variable TypeScript infiere el tipo que será a lo largo del código y este no puede variar. Por ejemplo:
let myName =""Victoria"";
Si bien no indicamos el tipo de dato como se haría de esta manera:
let myName:string=""Victoria"";
TypeScript infiere que la variable myName será del tipo string y en adelante no podrá tomar un valor que no sea de este tipo de dato.
myName =30;//Nos señalará como error pues se le quiere asignar un número a una variable de tipo string.
En Visual Studio Code puedes obtener autocompletado teniendo sugerencias según el tipo de dato que sea la variable:
Nombres de variables iguales
TypeScript te indicará como error aquellas variables con el mismo nombre a pesar de estar en archivos distintos. Esto no sucederá en entornos preconfigurados como por ejemplo Angular o React, ya que estos trabajan de forma modular o tienen un alcance (scope) para cada variable.
Si deseas trabajar con los mismos nombres de variables en diferentes archivos, puedes crear una función anónima autoejecutada:
(()=>{let myName =""Victoria"";})();
Lo mismo por cada variable que desees tener el mismo nombre (myName para este ejemplo) deberás crear este tipo de función para evitar que te den estas advertencias.
En el anterior curso 2020 de TS el profesor expostaba un objeto vacio para poder quitar los errores del editor:
export{}
Sin embargo, nunca entendí bien el porqué, aunque tenga más líneas de código, creo que es mejor practica la que se ve en esta clase.
Pienso que se debe al tipo de alcance que tiene la variable. Tenemos: global scope, function scope y block scope. Pienso que en un proyecto real, junta los modulos en un solo JS transpilado, al repetir nombres de variables se pueden sobreescribir. Por ello usa el "export" que es cuando exportas e importamos modulos donde por el function scope, esas variables solo existen dentro de ese modulo.
Sip, en el curso de TS con el otro profe usaba el export {} y que a ser verdad parece mas facil de usar en estos casos.
Inmediately Invoked Function Expression (IIFE).
También se pueden usar para simular un 'top level await':
(async()=>{...const students =awaitwindow.fetch(...)...})()
No sabia que se llamaba asi y lo ocupaba para hacer conexiones a mongoDB jaja
El código que has proporcionado es un ejemplo de una Inmediately Invoked Function Expression (IIFE), que se utiliza para ejecutar una función inmediatamente después de su declaración.
.
En el ejemplo dado, se declara una función anónima asíncrona utilizando la sintaxis de funciones flecha (async () => { ... }). Esta función se invoca inmediatamente mediante los paréntesis finales () al final de la declaración de la función.
.
Dentro de esta función, hay una línea de código que utiliza await para esperar a que la función fetch() de la ventana (window.fetch()) obtenga los datos de los estudiantes. El uso de await indica que esta función es asíncrona y que se espera a que la operación de obtención de datos se complete antes de continuar ejecutando el código dentro de la función.
.
En resumen, este código crea una función asíncrona y la invoca inmediatamente. Dentro de la función, se realiza una operación de obtención de datos asincrónica utilizando fetch(). El uso de una IIFE permite ejecutar este código de forma inmediata y controlar la asincronía mediante el uso de await.
Les recomiendo la extensión Error Lens en VSCode.
Te permite ver los errores en tiempo real y te indica en la misma línea, en donde tenés el error y la descripción del mismo.
Ejemplo:
muy buena :)
De esta clase podemos concluir:
TS usa tipos inferidos para "asignar" tipos de datos a variables sin que se las tengamos que asignar de manera explicita
Entre los beneficios de usar TS esta el hecho de que tenemos los metodos usados a cada tipo de datos, como en el caso de una variable "string", podemos acceder a el método toLowerCase de manera mas rápida
Al no tener aun modularizacion, TS nos alerta de que ciertas variables ya han sido declaradas, esto lo podemos prevenir con funciones anónimas autoejecutadas
Correcto, además está la opción de Literal Narrowing, en la cual Typescript nos ayuda a poner tipos específicos a nuestras varibles que usan const.
const myVariable = 123
En este caso la inferencia en vez de ser tipo number, será tipo "123".
una función anónima auto-ejecutada :
(()=>{})();
Así es, pero el nombre designado a éste tipo de funciones se les conoce como IIFE (Immediately Invoked Function Expression). Sólo como dato para quien no las conozca :)
Nose si es una actualizacion en TS pero a mi no me sale el error por usar la misma variable en otro archivo, que procede instalé mal las cosas o si es una actualización?
No hay ninguna ventaja de utilizar un arrow function en un **IIFE **(Immediately Invoke Function Expression) por lo cual usar una funcion normal me parece mas correcto
(function(){})()
la ventaja es menos código.
Les comparto mis apuntes. :D
Tipo de dato inferido
Sin necesidad de especificar el tipo de dato, TypeScript supone o deduce el mismo con el valor que le asignamos a la variable.
Es recomendable usarlo por encima del tipo de dato explico cada vez que sea posible.
Variables (let y var)
En TypeScript nos dice el tipo de dato que tienen que recibir estás variables, ya que como son variables pueden solamente cambiar a lo largo del programa pero solo por ese tipo de dato.
Constantes (const)
Aquí TypeScript no nos dice tipo de dato de nuestra constante, porque como su nombre lo indica, la misma no puede cambiar a lo largo del programa por otro valor.
Funciones anónimas autoejecutable
((parameters)=>{ statements
})();
Les comparto otras formas de crear funciones anónimas auto-ejecutables
No me salio el error, tuve que investigar y resulta que una novedad de la actual version de typescript 5.9.3 en 2025 en en archivo tsconfig.json tiene una nueva propiedad :
"moduleDetection":"force",
Esta propiedad trata a cada archivo como un modulo con su scope independiente a los demás archivos aunque no estemos usando módulos cada variable puede ser nombrada de la misma forma en destinos archivos sin chocar.
Pero aun asi puedes seguir usando el modo legacy para ser mas estricto por asi decirlo:
"moduleDetection":"legacy",
También esta el modo auto que este detecta si es o no modulo
"moduleDetection":"auto",
Muchisimas gracias por ese gran aporte!
Esas funciones se les conoce como IIFE (Immediately Invoked Function Expression)
Acá te dejo la documentaciòn
Ese Tipo de función es llamado Función IFEE (Immediately-invoked function expressions y este tipo de función se manda a llamar por si sola. Se puede escribir como arrow function o function declaration
(()=>{})()(function(){})()
¿Al escribir TS, debo poner al final el ";"?
VSCode no me marca error, así que supongo que es opcional.
Sí, tienes razón esto de ; es opcional, aunque puedes agregar reglas de ESLint para que te lo obligue a colocar.
Podés usar la siguiente regla en ESLint, en tu .eslintrc, para que sea obligatorio el uso de ;.
"rules":{..."semi":[2,"always"]}
muy interesante, siempre escuchaba sobre TS pero no habia tenido la oportunidad ni la necesidad de usarlo, pues definitivamente me esta gustando TS....
//* Función anónima autoejecutada(()=>{let myProductName ='Product 1'let myProductPrice =123//!myProductName = 123 no podemos hacer esto myProductName ='change' myProductName.toUpperCase() myProductPrice.toString()const myProductStock =1000//! myProductStock = 2000; no podemos hacerlo porque es una constante})();//* Hacemos esto para poder usar los mismos nombres de variables en otros archivos de TS.
Aquí te muestro varias formas de evitar las advertencias de TypeScript sobre la asignación de un número a una variable inferida como string utilizando diferentes enfoques:
.
Utilizar any:
let myProductName:any='Product 1';let myProductPrice:any=123;myProductName =12321;// Sin alerta de TypeScript
Al asignar el tipo any a las variables, le estás diciendo a TypeScript que permita cualquier tipo de valor, lo cual incluye la asignación de un número a una variable inferida como string. Sin embargo, debes tener en cuenta que el uso excesivo de any puede eliminar gran parte de los beneficios de TypeScript, ya que pierdes el control de tipos estático.
Utilizar unknown:
let myProductName:unknown='Product 1';let myProductPrice:unknown=123;myProductName =12321;// Sin alerta de TypeScript
Al utilizar unknown, estás indicando que no tienes información sobre el tipo de la variable. Al igual que any, unknown permite asignar cualquier tipo de valor a la variable sin advertencias de TypeScript. Sin embargo, al trabajar con variables de tipo unknown, debes realizar una verificación de tipo o una conversión explícita antes de realizar operaciones específicas del tipo.
Utilizar una anotación de tipo explícita combinando string y number:
let myProductName:string|number='Product 1';let myProductPrice:string|number=123;myProductName =12321;// Sin alerta de TypeScript
Como mencioné anteriormente, al utilizar una anotación de tipo union (string | number), le estás indicando a TypeScript que la variable puede ser tanto una cadena de texto como un número. Esto permite asignaciones de ambos tipos sin mostrar una advertencia.
.
En general, se recomienda utilizar las anotaciones de tipo más específicas posibles en lugar de any o unknown, ya que te permiten aprovechar los beneficios del sistema de tipos estático de TypeScript y detectar errores potenciales en tiempo de compilación. Sin embargo, en situaciones específicas donde necesites flexibilidad extrema o cuando no tengas información sobre el tipo de la variable, any o unknown pueden ser opciones válidas.
Aquí tienes ejemplos prácticos donde el uso de any o unknown puede ser útil:
.
Ejemplo con any:
Supongamos que estás utilizando una biblioteca de terceros que tiene una función que puede devolver diferentes tipos de resultados. En este caso, no tienes información precisa sobre el tipo de retorno de la función. Podrías usar any para asignar el resultado de la función sin generar advertencias de TypeScript.
let result:any=thirdPartyLibraryFunction();// Puedes utilizar 'result' sin advertencias de TypeScript// ya que está marcado como 'any'
En este escenario, el uso de any te brinda la máxima flexibilidad para trabajar con el resultado de la función sin restricciones de tipo. Sin embargo, debes tener cuidado al utilizar any y asegurarte de realizar las comprobaciones necesarias para evitar errores en tiempo de ejecución.
.
Ejemplo con unknown:
Supongamos que estás procesando datos dinámicos de una fuente externa y no estás seguro del tipo de los datos recibidos. En este caso, puedes utilizar unknown para asignar los datos sin generar advertencias de TypeScript. Luego, puedes realizar verificaciones de tipo o conversiones explícitas según sea necesario.
let data:unknown=fetchDataFromExternalSource();// Realizar una verificación de tipo antes de utilizar los datosif(typeof data ==='string'){// Procesar los datos como una cadena de textoconsole.log(data.toUpperCase());}elseif(typeof data ==='number'){// Procesar los datos como un númeroconsole.log(data *2);}else{// Otros casos}
En este ejemplo, el uso de unknown te permite manejar datos dinámicos sin tener información precisa sobre su tipo. Puedes realizar comprobaciones de tipo o conversiones explícitas para trabajar con los datos de manera segura y evitar errores en tiempo de ejecución.
.
Recuerda que aunque any y unknown ofrecen flexibilidad, también conllevan el riesgo de perder los beneficios del sistema de tipos estático de TypeScript. Por lo tanto, es recomendable utilizarlos de manera responsable y realizar las verificaciones de tipo necesarias para mantener la seguridad y confiabilidad del código.
a example :3
let myProductName ='producto';// tipo inferido (ya es una variable de strings)let myProductPrice =12;// tipo inferido (ya es una variable de tipo number) myProductName =2;// ERROR! NO SE PUEDE ASIGNAR UN NUMERO A UNA VARIABLE DE TIPO STRINGmyProductName ='cambio';// BIEN :) myProductPrice ='hola';// ERROR! NO SE SE LE PUEDE ASIGNAR UN STRING A UNA VARIABLE DE TIPO NUMBERmyProductPrice =22;// BIEN :)
¿Por qué no se debe poner siempre el tipo de dato de forma explícita? No sería mejor ponerlo vara evitar por ejemplo casos en los que el motor de inferencia pueda cometer algún error o simplemente evitar que al compilar tsc tenga que hacer una revisión del código para agregar los tipos.
Hola, Andrés.
Precisamente el compilador de ts permite inferir eso de forma interna. Creo que lo más común es utilizarla de forma explícita.
Saludos.
Hola, Andrés
Como dice el profesor, hay casos en los que se utiliza la inferencia de tipo y casos en los que es mejor ser explícitos. Utilizar la inferencia es aprovechar esa característica de TS (existe por algo). La inferencia ayuda a ahorrar líneas de código ya que poner el tipo puede hacer tu código más verboso y, a veces, redundante. Respecto al error del compilador, bueno, la inferencia es en función al valor que asignas así que digamos que el compilador confía en lo que haces.
Hola buenas, algo qu eme genero bastante duda, es si TS no me permite tener dos variables del mismo nombre en mi poryecto, Js si lo permitiria, y "digamos que si pero no", como asi, En JavaScript, cuando defines una variable const o let en archivos separados y no las importas ni las ejecutas juntas en un solo archivo, JS no lanza un error porque no hay un análisis global de todas las variables entre diferentes archivos, lo que significa que:
Cada archivo que ejecutas en JS tiene su propio ámbito local, a menos que lo combines en un entorno (como un archivo html, donde usamos los scripts con los codigos Js).
Si ejecutas un solo archivo, JS no tiene "conocimiento" de que en otro archivo existe una variable con el mismo nombre.
entonces lo probe y efectivamente asi es, cuando colocas un index.html y le colocas los dos scripts al estar en el mismo entorno sale error de dicha variable, entonces por que TS si salta el error aunque los archivos no tengan un mismo entorno como un html; En TypeScript, si defines una variable con el mismo nombre en dos archivos del mismo proyecto, el compilador analizará todos los archivos dentro del contexto del proyecto. Esto significa que si hay dos variables const a = 10; en diferentes archivos .ts, TypeScript detectará que se está usando el mismo nombre, lo que podría causar conflictos, especialmente si estas variables están en el mismo ámbito global. es por esto que se usa el Immediately Invoked Function Expression (IIFE) para darle un contexto diferente y no genere el error.