TypeScript: TYPES vs INTERFACES - Cuándo usar cada uno

[@CodelyTV]

Y tú qué prefieres… ¿Tipos o Interfaces? 🤔

[@shaquespiare]

Mi primer lenguaje fue Java, por lo tanto conocí las interfaces desde mis inicios, hoy las aplico por defecto por sobre los tipos, exceptuando en ocasiones donde las características únicas de los tipos sean necesarias, me gustó saber de algunas características que no conocía de los tipos, tema muy interesante

[@jcuervas]

Interesante video. Como detalle, os habéis dejado un uso muy frecuente de tipos que es el definir tipos para delimitar valores, por ej. type HttpMethod = 'POST'|'GET'.

Depende, uso types para cosas más concretas o para atributos o métodos mientras que uso interface para modelar api/objetos. En general, en el equipo, damos cierta libertad pero animamos al uso de interface que, a mi parecer, da un sentido mayor cuando se trata de extender un objeto. De cualquier modo, gran vídeo y muy buena explicación. Le he echado en falta en la sección de extensión profundizar un poco más.

Excelente explicación y comparto la opinión de xavi

[@cesarmorales5708]

Muy bueno. la verdad. yo por ejemplo suelo usar interfaces el 90 % de las veces.

[@Colmedoherman]

En mi equipo usamos interface, porque siempre la puedes hacer evolucionar, si la usas como "type" siempre le podras añadir metodos sin que rompa tu codigo existente, en el caso contrario puede ser mas confuso

[@stevengpa]

La música 😁, muy buen vídeo 🙂👌🏻

[@jetox21]

Brutal, siempre uso interfaces y los tipos solo para unir tipos primitivos o interfaces, sobre todo cuando uso genéricos es que hago esto de los tipos

[@plasmodiun1]

Igual hago lo mismo

[@robertov2554]

a mi me gustan las interfaces para proyectos un poco mas grandes y que requieren tener identificados ciertas familias de objetos que necesitan tener propiedades iguales, pero typedef para típica API en NodeJS o para una app sencilla en Angular typedef crema

[@moviedomof]

Declaration merging puede ser util por si ya tienen iuna Interfaz creada que viene de otros desarrollos y la quieres extender como se hace con c# con clases parciales .. Suele ser muy util para separar en archivos desarrollos de estaticos de interfaz (provenientes de un codeGen por ejemplo ) y luego el desarrollador solo toca sus archivos " partials" para customizaciones en c/proyecto . Un commit no afectaria nunca la clase original (por asi decirlo)

[@FerminDevMobile]

Exactamente, de esa forma el dominio queda protegido. En dart se llama Extension method, es una maravilla.

[@misaelpereira9679]

Hombre, para modelar datos de cliente/servidor, creo que viene handy los types

[@robertov2554]

brutal la funcionalidad de la interface "Declaration merging"(no la conocia), para proyectos que encadenan llamadas a servicios y que entre alguna de esas llamadas puede o no recibir informacion auxiliar que es necesaria(si la recibes) para las siguientes llamadas a servicios, lo cual hace posible que pueda seguir usando mi interfaz base para ciertos objetos, añadiendo esa variable por el camino que se vuelve necesaria en las siguientes peticiones. CREMA

[@SimaDamian]

No... huele feo! xD. generate un nuevo tipo y listo, es mas entendible. ¿Conoces el concepto de partial class? bueno. Es solo dolor de cabeza para el que hace mantenimiento.

[@crackzz8913]

@@SimaDamian lo mismo pensé. Cuando vi eso me pareció muy feo , para eso están los Partials

[@SimaDamian]

Buenas! aclaración: - Donde dice "sobreescribir tipos" no es así, no estas sobreescribiendo nada, estas solo definiendo el tipo Name que es identico a un string. - Interface "Declaracion merging" parece mas un bug que otra cosa, existe el concepto de clase parciales, que es algo parecido, pero a nivel interfaz parece mas un bug que otra cosa. Comentario, yo evito las interfaces para modelado de datos, (si las uso para contratos) ya que las operaciones de typos para generar un nuevo tipo no funcionan en interfaces, ej: ``type Res = Exclude`` si *TInner* es una interfaz el nuevo tipo *Res* no tiene definicion, en cambio si es tipo *type* si funciona correctamente.

[@eriksostenes4234]

Una pregunta, puedo comprar un curso por separado, o necesito comprar toda una suscripción por todo un año.

[@CodelyTV]

Puedes suscribirte 1 sólo mes 😊 Te sale a 29€, que con que hagas un sólo curso ya es un buen precio, y además podrás hacer cualquiera de los demás y los que publicamos cada semana 🤟 Aquí más info del por qué no vendemos cursos sueltos: soporte.codely.com/es/articles/4387186-puedo-comprar-un-curso-por-separado

[@eriksostenes4234]

@@CodelyTV gracias

[@ferriss_]

+100 al "Adiós" al final del vídeo 😆

[@josergdev]

Buen video. Creo que los types marcaran la diferencia cuando incluyan "Exhaustive pattern matching" si lo hacen... Hay alguna proposal

[@CodelyTV]

De momento podemos al menos garantizar exhaustividad con algún truquillo gracias a never 😬 aquí lo vemos: kzbin.info/www/bejne/noW3nHaVm8aiaaM

[@misaelpereira9679]

Typescript's Class: "I am joke to you?"

[@dodo11858]

Yo solo uso types, al final si este te aporta más y/o mejor funcionalidades si que están claras las diferencias y hay un claro ganador. Es absurdo ponerse tan tiquismiquis con la semántica, pero bueno, muy opinionated.

[@lawrent6209]

Quien gano ?xD

[@washimon7]

Yo uso los 2

[@mauroinde]

la vieja confiable es ANY

[@jdiazco]

a TYPE cannot be re-opened to add new properties VS an INTERFACE which is always extendable.

[@xsrpma]

Inline tipos, multiline interfaces xD. Revisare cual es el javascript que genera cada cual

[@SimaDamian]

debería ser el mismo porque el tipado no afecta js

[@jcuervas]

La respuesta es ninguno, si quieres que la compilación de js mantenga referencia al tipo debes crear clases, que si existen en js

[@tacodelmetro8385]

Developer raro el que usa el tema claro en el IDE.

[@SRG-Learn]

Dark Fucking Mode!! Also intro music it's too loud.

[@GuillermoDeLosSantos]

coño cuanta publicidad....