Martin Alejandro Tecún Charles
Platzi Team
Miguel Peláez
Martin Alejandro Tecún Charles
Platzi Team
Miguel Peláez
Jose Daniel Barría Reyes
Miguel Angel Reyes Moreno
Juan José Alexander Ordoñez Tupul
Raul Hernández
Moisés Manuel Morín Hevia
Sergio Brandon De Lucio Chavero
Boris Vargas Paucara
Moisés Manuel Morín Hevia
Jorge Cruz Perez
Jaime Gabriel González Célleri
Fabian Andres Ramirez Vela
Moisés Manuel Morín Hevia
Francisco Javier Suarez Verdugo
Juan David González Rodríguez
Daniel Adolfo Ordoñez Rubio
Carlos Ortiz
Raul Armas
Irving Juárez
Miguel Angel Reyes Moreno
Diego Fernando Caviedes Camaho
Jainelker Jesus Yepez
Diego Fernando Caviedes Camaho
Karina Prado
Andrés Felipe Eslava Zuluaga
Moisés Manuel Morín Hevia
Fernando Molano Castrillón
Carlos Erices
Manuel Ojeda
Luis Aviles
ProfesorIrving German Manuel Molano Torres
Irving Juárez
German Vera
David Prieto Cornejo
Moisés Manuel Morín Hevia
Laura Roa
Ernán Alexander Velásquez Ramírez
Jeremy Palomino
No sé ustedes pero hasta este punto yo entiendo todo a la perfección que buen profesor 😃
Si, realmente es muy bueno el profe, se entiendo a la perfeccion
Muy clara la forma de explicar.
Propiedades opcionales : No todas las propiedades de una interfaz podrian ser requeridas. Usamos el simbolo '?' luego del nombre de la propiedad.
interface PictureConfig { title: string; date?: string; orientation: PhotoOrientation }
Propiedades de solo lectura: Algunas propiedades de la interfaz podrian no ser modificables una vez creado el objeto. Esto es posible usando readonly antes del nombre de la propiedad.
interface User { readonly id: number; username: string; readonly isPro:boolean; }
Buen resumen. Además el ejemplo del ID de la base de datos que el profe mencionó me parece que es el ejemplo perfecto.
Friendly reminder... La propiedades opcionales, es mejor dejarlas después de las propiedades requeridas.
Like si estas viendo esta clase en Mayo 2021
25-mayo-2021 (:
26-mayo-2021 :v
interface PictureConfig { title?: string; date?: string; orientation?: PhotoOrientation } function generatePicture(config: PictureConfig) { const pic = { title: 'Default', date: '2020-03' }; if (config.title) { pic.title = config.title; } if (config.date) { pic.date = config.date; } return pic; } let picture = generatePicture({}); console.log('picture : ', picture); picture = generatePicture({title: 'Travel Pic'}); console.log('picture : ', picture); picture = generatePicture({title: 'Travel Pic', date: '2012-05'}); console.log('picture : ', picture); // Interfaz: usuario interface User { readonly id: number; // solo lectura username: string; isPro: boolean } let user: User; user = { id: 10, username: 'luixaviles', isPro: true } console.log('user : ', user); user.username = 'paparazzi'; // user.id = 20; // --> Error console.log('user : ', user);
Thanks,
referente a mi pregunta anterior, con type también puse la sintaxis de opcional y funciono, por lo mismo no estoy seguro cual leva mejor si interface o type, mas que nada porque controla los parámetros que le enviamos a una función y no tanto por como se usa interface cuando usamos implements.
Si muy bien explicado, y los ejemplos son muy prácticos
Demasiado, todo va sobre ruedas.
Estupenda clase instructor Luis, me agrada como podemos establecer una estructura para los objetos que se van a manipular y el readonly será bastante útil a la hora de tener datos que no queremos que se modifiquen una vez recibidos.
Que diferencias hay entre type y interface?
Hola, Juan :) Yo creo que lo explican bien en este artículo, pero te voy a dejar el resumen.
Consideremos primero que en TypeScript existen tipos de datos básicos, como: Boolean, Number, String, Array, Tuple, Enum, Unknown, Any, Void, Undefined, Null, ..., Object, etc., y sus derivados. Y tipos de datos avanzados, como los definidos por usuario.
interface defines la forma que tienen los valores de un objeto, por ejemplo, ciertos atributos y sus nombres.type creas una definición para un tipo de datos, que puede ser un primitivo, o cualquier otro tipo de valor; y le asignas un alias a esa definición.Las interfaces son poderosas porque puede ser extendida, implementa, o ser el resultado de una fusión (merge), y permiten mantener un control sobre la definición de los objetos.
Usar type es conveniente porque permite controlar los valores que puede tener un tipo (definido por su alias), usando tuplas, union (|), o intersección (&).
Tipos básicos Tipos avanzados Interfaces Typos literales
Basicamente que la interfaz permite ser extendida o se puede ir adaptando(añadir nuevos tipos) mientras que un type no le podemos extender ni aumentar sus capacidades. Mira este link
Buen profesor, pero no va al grano, todo esto pudo haberse explicando en 3 mins o menos...
Sin embargo, menciono casos de uso que suelen ser aplicables en la vida real. Se pudo haber explicado en 3min, pero probablemente hubiéramos tenido que ver este video de nuevo en el futuro cuando usáramos esto en la vida real
Interfaces: propiedades opcionales
No todas las propiedades de una interfaz podrían ser requeridas.
Establecemos una propiedad como opcional con el símbolo '?' después del nombre.
interface PictureConfig { title?: string, //* El '?' indica que el parámetro es opcional date?: string, orientation?: PhotoOrientation } function generatePicture(config: PictureConfig) { const picture = {title: 'Default title', date: '2020-01-01'} //*Valores por defecto if (config.title) { picture.title = config.title } if (config.date) { picture.date = config.date } return picture } let picture = generatePicture({}) console.table({picture}) picture = generatePicture({title: 'Travel Pic'}) console.table({picture}) picture = generatePicture({title: 'Travel Pic', date: '2016-06-23'}) console.table({picture})
Interfaces: Propiedades de solo lectura
Algunas propiedades de la interfaz podrían no ser modificables una vez creado el objeto. Esto es posible usando readonly antes del nombre de la propiedad.
//* Interfaz: Usuario interface User { readonly id: number, username: string, isPro: boolean } let user: User = {id: 10, username: 'Mike', isPro: true} console.table({user}) //*modificamos ahora un campo //! user.id = 20 ahora no podemos modificar este campo user.username = 'paparazzi' console.table({user})
que quiere decir el signo ??
Hola Diego. Los signos de interrogación en la variable de TypeScript se utilizan para marcar esa variable como una variable opcional. Si ponemos el signo de interrogación al declarar una variable, esa variable se vuelve opcional. Los parámetros opcionales tendrán un valor indefinido cuando no se utilicen.
Sintaxis:
function A(x?: number) { // Function_body }
me refiero al doble ?? signo de interrogación. lo he visto en algunas ocasiones.
Solo quiero mencionar que la forma de explicar del profesor es muy buena, todas las clases desde el inicio son bastante entendibles, un capo.
readonly se define que algunas propiedades podrían no ser modificables.
.interface User { readonly name?: string; readonly age?: number; isPro?: boolean; } let user: User; user = {name: 'Andrés', age: 27, isPro: true} user.name = 'Felipe'; // This will not change the object, so is the reason for readonly /** Error: (property) User.name?: string | undefined * Cannot assign to 'name' because it is a read-only property. * */
Buen aporte !
Se puede definir solo 1 de los 3 parámetros como opcional? Es decir, quiero que el title y orientation sean requeridos pero el date optional.
Si agregó ? solamente al date, el editor me marca error.
¿qué es mejor usar Interface o enum?
Son dos características muy diferentes. enum se trata de crear opciones como valor que tendrá tu variable. interface se trata de un contrato como tal que puede tener muchas variables que debe de cumplir para satisfacer dicho contrato.
Dentro de una interface pueden existir enum's, pero no interfaces dentro de enum's.
Hola,
Puedes pensar en usar enumerados cuando tienes un conjunto de valores que pueden representarse como constantes: los días de la semana, los puntos cardinales, meses del año, los planetas del sistema solar, etc. Los enumerados permiten asignar un nombre comprensible y fácil de identificar a dichas constantes :-)
Por otra parte, puedes pensar en usar interfaces para abstraer un objeto en particular, un modelo, un contrato: Usuario, Curso, Vehículo, etc.
Apesar que declare como readonly una propiedad de la interfaz, de igual manera se cambio su valor.
Si, yo también lo noté. Lo que pasa es que es solo un error del compilador, lo que significa que el único error que te va a salir es el subrayado de color rojo mencionándote que no puedes hacer tal o cual cosa. Sin embargo, si lo compilas con todo y el error, en la consola no hay como tal un error
Por que al sobrescribir el valor del atributo de un objeto que es solo de lectura, en javascript lo sobrescribe?
interface User { readonly id: number; username: string; isPro: boolean; } let user: User; user = { id: 2, username: 'luis', isPro: true }; user.id = 3; // Error, pero en javascript si lo sobrescribe user.username = 'moraes'; console.log(user);
Básicamente porque Js no es un lenguaje tipado, por eso es que existe Ts. Pero Ts solo tiene sentido en tiempo de compilación, mostrando errores y arrojando excepciones, es una herramienta para el desarrollador.
Si bien Ts compila a Js, no tiene la facultad para forzar funcionalidades que Js de base no soporta. Por ej.
/*TS*/ let Bar: string = 'Mi cadena'; Bar = false; //error TS
Si bien la asignación a boolean es entendida como un error para Ts, esto se compila a:
/*JS*/ let Bar = "mi cadena"; Bar = false; /*Ok*/
Let admite cualquier tipo de primitiva del lenguaje de Js. No obstante, talvez en el contexto de tu app esto podría devenir a un error en tiempo de ejecución, dado que Bar debía procesarse como una cadena. Ts te ayuda entonces a preveer el error en tiempo de compilación!
Lo va a sobreescribir en JS pero en TS te va a marcar error (osea va a correr pero vas a tener errores) Js es debilmente tipado el compilador del navegador va a interpretarlo.
Hola a todos! Estaba demasiado perdida en este tema y leí este articulo y me aclaro muchas dudas y ya viendo el video entendí mucho mejor todo! https://www.tutorialsteacher.com/typescript/typescript-interface
We can write interfaces with comma and semicolon. They both are valid but it's needed a consistency. TS prefers semicolon to comma. Source
interface User { readonly id: number username: string isPro: boolean }