Pare de Usar TypeScript - Interfaces (Types vs. Interfaces)

[@ApenasmaisumDev]

O Cara escreve um artigo sem saber usar direito, deve ser um Sênior de 6 meses.

[@filipeleonelbatista]

Ou gerado por IA 😂

[@potors]

@@filipeleonelbatista foi o que eu pensei, ele com certeza mudou alguma coisa mas tava muito bêbado porquê esse final não teve nexo nenhum

[@NetoNeto]

@@filipeleonelbatista lendo o texto, eu notei umas palavras fora do lugar, e aí pensei que o cara usou um translate da vida para copiar texto de artigo gringo. Para piorar, o exemplo do cara é o mesmo da documentação original... tudo muito estranho os elementos usados para construir o artigo do cara. Pode mesmo ter sido algo gerado automaticamente

[@randerins]

traduzido pelo Google

[@LucasLima-hj5sg]

"Quando eu virar sênior, não vou falar sobre o que não sei. Tem que ser humilde né kkk" Eu com 2 meses de sênior: "Saiba porque você deve usar 'x' e não 'y'"

[@luizhenriquelobo]

Esse final com o Lucas dando like no comentário e o mesmo virando um NaN e ele "isso foi feito em TS" eu rachei, KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK

[@tarcisiome]

O melhor é você fazer um código/tipo mais fácil e legível para o próximo DEV, porque o próximo DEV pode ser você.

[@filipeleonelbatista]

Python no C# do proximo dev. Ninguem pensou em mim na minha vez.

[@tarcisiome]

@@filipeleonelbatista essa foi boa kkk

[@peristiloperis7789]

No meu caso o próximo dev sempre sou eu. E eu nunca entendo o que eu mesmo escrevi. Só preciso de 3 dias pra tudo tudo ser apagado da memória lol

[@jbfaneto]

vou colocar essa gambiarra aqui, vai ser a ultima vez que eu irei mexer no código -> eu mesmo na semana que vem sofrendo para lembrar o que foi aquilo que eu fiz hahaha

[@peristiloperis7789]

@@jbfaneto exato! mas aí que vc começa a melhorar d verdade.

[@lucasjsantos2260]

Amigos. Type existe até em Haskell que é uma linguagem puramente funcional. Interface é um conceito específico de OO. Comparar Type com Interface faz tanto sentido quanto comparar um alicate com uma escova de dente.

[@douglasmiguel7149]

a melhor analogia para este exemplo de interface e implementacao que ja vi foi quando decompilei o minecraft.. la temos a interface block e todos os outros blocos implementa essa interface, é muito legal! fica aqui o exemplo: interface Block {} class RedStone implements Block {}

[@ps_layne]

5:40 "eu só posso tá ficando maluco" esse é o sentimento

[@magodevofficial]

Tu reconhece um javascripto quando ele vem com o papo de "qual é melhor que qual"

[@JonatanEdOrtiz]

Às vezes eu acho que pra escrever esses artigos os caras simplesmente começam a estudar algo novo e então colocam dentro do artigo todas as dúvidas que eles têm enquanto elas surgem e depois no próprio artigo vão anotando o que descobrem no meio do caminho até chegar à conclusão que responde a dúvida que ele tinha. Aí escrevem isso de uma forma como se estivessem ensinando, mas na verdade estão aprendendo.

[@kbarreto]

Profundo

[@arthuralk]

Pior que é uma boa técnica. Se perguntar, ninguém responde. Se descer o cassete vem uma enxurrada de resposta

[@brendonoliveira2142]

No projeto que trabalho eu utilizo bastante a funcionalidade de Merging das interfaces para tipar os propriedades dos componentes de DSMs (cada dsm é um pacote npm). Tenho um "DSM" common que declara componentes que recebem um token de cor, mas quem de fato define quais são os valores que existem para o token de cor são os DSMs especificos. - DSM Base -> Define Interface BaseColor - DSM Components 1 -> Redefine Interface BaseColor com seus valores unicos - DSM Components 2 -> Redefine Interface BaseColor com seus valores unicos O ponto é que como um projeto pode utilizar multiplos DSMs, utilizar o Merging nas interfaces se torna muito mais escalavel e não preciso ter uma "dependencia circular" entre os pacotes.

[@246bits]

"Person extends Job" é uma loucura que não faz nenhum sentido na minha cabeça. Uma pessoa NAO É um trabalho, ela TEM um. O Job precisaria entrar como atributo da classe Person assim como nome e idade...

[@wagmit]

em go isso fica delicinha, fazer uma composition e ser feliz

[@amagami1008]

Mas os humanos nasceram para trabalhar e apenas isso

[@twchronous]

interface PersonInterface { name: string job: JobInterface } essa é a implementação que pra mim deixa da maneira mais clara possível o código

[@marceloamp2]

Faria mais sentido Person extends Employee (funcionário)

[@matheuscadenassi6714]

​@@marceloamp2 tá meio ruim ainda amigo. Uma Person não é necessariamente um Employee, mas um employee tem que ser um Person. Acho que ao contrário faz mas sentido ou eu que não entendi direito...

[@akifer2521]

7:00, a implementação ideal seria criar um tipo específico para o trabalho e definir que o campo job dentro da interface Person utiliza esse tipo. Exemplo: type Job = { name: string; } interface Person { name: string; age: number; job: Job; }

[@GabrielSouza-sz5ju]

Você também pode usar `implements` com tipos em TypeScript. Tipos possuem todas as funcionalidades de interfaces (menos a habilidade de ser modificado, o que pode na verdade ser um benefício) com uma sintaxe mais simples. Além disso tipos são mais versáteis, podendo conter não apenas objetos como também pode ser um apelido pra outro tipo mais simples ou union (como mostrado no vídeo). O recomendado é usar tipo por padrão a não ser que você queira que seu contrato seja modificado. Pra quem quiser saber mais sobre tipos x interfaces checa esses vídeos (em inglês): /watch?v=zM9UPcIyyhQ /watch?v=Idf0zh9f3qQ /watch?v=oiFo2z8ILNo

[@TheJunioGG]

Ótimo comentário, o Lucas no geral tem razão, o problema é que a abordagem do Typescript para interfaces e tipos ficou uma PORCARIA. sem contar que o cara aprendeu Typescript somente para front e usar no projeto react dele, onde ele só precisa passar tipos ou interfaces para uma Props de um Component. Isso faz pensarmos em pq as pessoas estão realmente usando Typescript no frontend é um monte de copia e cola.

[@nathanmiguel76]

Montano tá ficando igual o Vegeta.

[@phlimma]

Ele está virando o Pica-Pau com esse topete dele.

[@israelpablocoelho2229]

ahahhaahhaahahhaha

[@TheDanilove90]

Ele vai ser escalado na continuação de Dragon Ball Evolution

[@jordhan]

Eu to fazendo um frontend todo em Typescript, minha regra geral é: Eu preciso limitar apenas UM valor? Type. Exemplo: type positions = "left" | "center" | "right" | undefined; Preciso de algo para garantir quais campos vão se passado de A para B? Interface.

[@rodrigobleao]

eu tbm estava trabalhando assim, mas esse vídeo começou a me fazer questionar se isso é bom kkk

[@yblindz]

18:34 não precisaria nem extender, poderia só definir o tipo job como opcional na interface, dai caso um valor fosse passado na declaração do objeto ele seria aceito e se não fosse também. Salve Lucas!

[@devspeedrun]

Regra de um typescript, esqueça tudo que aprendeu em POO

[@helciopandelo]

Nem a pau, é justamente pra vc usar. Ele tem uma "flexibilidade" que vem herdada do JS, mas é pra ser POO normal. Em resumo, n é pq te permitem fazer "cagada" que é pra vc fazer kkk

[@devspeedrun]

@@helciopandelo Sei disso, mas digo pela maioria dos iniciantes ou aqueles que so utilizam a tech sem saber do background, que so copia de tutorial no yt

[@felipemoreira4286]

Achei muito interessante pq sua visão não é viciada só no javascript mas trazendo visão de outras linguagens isso e muito rico. Obrigado!

[@bcampera]

Como javeiro, não entendo a ideia interfaces com campos 😢 pra mim deveria ser definição de comportamentos públicos

[@davidalexandre4103]

Eu penso da mesma forma kkk, pra mim interface é contrato pra colocar actions, métodos, voids e etc, se for para colocar campos não vejo pq não usar type ou até mesmo class

[@LucasSantos-oc6fx]

Como um c#peiro devo concordar e pra mim em todo momento que ele disse interface eu entendia como classe abstrata

[@dasmonstrum27]

@@LucasSantos-oc6fx TypeScript veio do C# e não tem nenhuma diferença gritante nas interfaces entre eles, só um ou outro truque minúsculo novo do dotnet 9

[@mso2000]

É porque javeiro não sabe que em linguagens modernas (kotlin, Swift, etc), você consegue expor campos apenas como leitura, então você não precisa de getters e pode colocá-los nas interfaces sem problema... 😜

[@titbarros]

A verdade é que a nomenclatura do TS é ruim. Na real, é tudo tipo. Lembra que é js. Tudo é object. A principal diferença é a capacidade da interface ser extebdida em qq ponto da aplicação. Ela é um tipo "global". E isso é bom apenas em alguns casos e muito perigoso em outros. Esse é o ponto do artigo. Mas bem fraquinho

[@gabrielcanuto3321]

Seguiu o mesmo roteiro do primeagen. Mas cá entre nós o conteúdo ta em português e mostra justamente que existe muito conteúdo por ai não tão bom (e as vezes dando informações erradas como este que foi avaliado). Precisamos de mais caras como você, fortalecendo os dev br. Parabéns

[@LucasMontano]

não sei se ele gravou sobre esse artigo ou não, talvez… também pego conteúdo do Reddit

[@brenoepic6946]

prime mentioned

[@LucasMontano]

The Name: Lucas Montano do canal Lucas Montano

[@menegatmarcelo]

Essas discuções em TS são as mais divertidas! Seja o que for o assunto, no final tudo se resume a Obejtos e prototypes. JS rules, TS sempre foi e sempre vai ser só um linter gourmentizado! 🤷‍♂

[@matheusaugusto6701]

Caramba, Lucas, obrigado por esse vídeo. Estou num projeto há dois anos e hoje fui revisar essa parte de tipagem que fiz lá atrás e as entidades estavam tipadas com type. Até mesmo algumas tipagens que herdavam propriedades de outras estavam declaradas como type entidade2 = entidade1 & {...}. Troquei para interface entidade2 extends entidade1 {...} Dessa forma fica muito mais semântico

[@jonasfrancomatador1277]

Eu acho que ele queria explicar as extensão das interface quando usadas em uma função: "function xxx()" onde pessoa receber a tipagem person e job. Mas seu exemplo esta vendo somente a interface sendo usada em classe. E nesse caso ele deu exemplo de um objeto que receber uma interface que receber outra interface como extensão.

[@thisgin]

Qual software e este q ele usa pra desenhar ?4:55

[@christoffersantos3419]

Artigo compara chave philips com chave de fenda e o problema de exemplo é qual é melhor usar para pregar um quadro na parede.

[@williamroger9375]

Mais um excelente vídeo, gosto muito de ver os vídeos do Montano porque tem sempre uma pequena aula dentro do vídeo.

[@lucacoLg]

Que aplicativo é esse de rascunhos e diagramas que vc usa??

[@joaov6727]

22 min aprendendo mais doq aprendi em 1 ano de faculdade, parabéns lucas montano do canal lucas montano

[@GKG0REE013]

17:06 observe como o Angular trabalha: export class StatusComponent { constructor(private data: DataService) {} }

[@mateuscardoso9635]

Muito foda, não tinha parado pra ver esse canal ainda.

[@danilonamitala4209]

Lucas, nesse seu exemplo em Kotlin (6:48) a relação de objetos ainda não estaria errada? Para mim uma vez que Job pode ser um objetos com outras propriedades, como salario, empresa, etc o correto seria colocar como sendo uma associação, ou seja Job seria uma Propriedade de pessoa, não uma extensão

[@eJuniorA2]

Eu acho declaration merging super útil pra extender interfaces globais. Se você está criando módulos por exemplo pode armazenar as extensões dentro do próprio módulo, fica tudo mais conciso e celular.

[@bishop244k]

Concordo, e costumo utilizar utilizar interfaces para estabelecer contratos de classes, e tipos para todas outras coisas como DTOs etc.. a criação de tipos complexos ou variável usando types fica bem mais legível, exemplo: type Person = { name: string lastname: string } type Street = { city: string state: string n: number } type Job = { position: string joinedAt: string } type PersonalInformation = { maritalStatus: T } //junção de tudo usando types e interfaces type Master = Person & Street & Omit & PersonalInformation interface Master1 extends Person, Street, Omit, PersonalInformation {} particularmente, a escrita de types pra mim fica mais fácil de ler e em interfaces você é obrigado a adicionar {} para o Typescript entender que você quer implementar uma interface, o que não faz muito sentido.

[@Kratos345ful]

Eu sou expert em Java, quando eu uso TS eu tento usar classe, type e interface como se tivesse em Java, e funciona de boa. Esse drama em cima de OO é coisa de quem só aprendeu o basico de JS e foi pro riéquiti

[@lucasfelipe-ze5sy]

O único problema das interfaces no TS é realmente o type merging, pois você pode acidentalmente declarar duas interfaces com mesmo nome e usá-las no mesmo escopo, o que poderia levar a um erro que não seria imediatamente identificável

[@rodrigosor]

@typescript-eslint/no-redeclare com ignoreDeclarationMerge

[@yuritavares1916]

17:06 "Uma pessoa não é o seu trabalho. Tu é muito mais que o seu próprio trabalho" - DO CANAL LUCAS MONTANO, Lucas Montano

[@REDIDSoft]

excelente vídeo Lucas Montano do canal Lucas Montano, se o cara fala que types são melhores que interfaces ou vice-versa, ele provavelmente não entende de types nem de interfaces kkkk, sucesso!

[@felipemoreira4286]

Muito bom seu vídeo Lucas, um problema que eu vejo e que typescript está virando meio que "padrao" usar typescript. Depois do seu vídeo e como o typescript t sido utilizado nos projetos pelos devs front, gostaria muito que vc assistisse o documentaria sobre a origem do typescript e entender a necessidade da Microsoft ter criado e fazer um vídeo sobre Ao meu ver não é todo projeto que é necessário ter typescript. Por exemplo em vue nos já temos como usar tipos nativamente então se eu bou usar typescript só pra definir tipos, já não preciso do typescript.

[@alisonhj]

Composition over Inheritance no caso do Job, pois a classe Person deveria ter uma propriedade job que pode ser nula assim: Person { ... job?: Job ... }

[@alisonhj]

Na verdade, a class Person devia ter um array de Job que pode ser nulo. Algo assim: class Person { jobs?: Job[] } Os "Job" que estarão vinculados ao Person, pois um Person pode ter vários ou nenhum job dessa forma

[@sedraccalupeteca5769]

Isto falo por mí, na maioria dos projectos que trabalhei com React e Vue usando TypeScript, a ideia de interface são aplicadas como DTO e tratadas como classes concretas, algo que de inicio mexeu com os meus conceitos, eu que sou do mundo Java ver uma interface com propriedades e sem nenhum método de contrato

[@randerins]

Atualmente, venho escrevendo (na verdade corrigindo) testes pra essa certa library promissora em TS que é gringa e gerou um grande impacto na comunidade no último ano. Esse certo arquivo de testes me foi apresentado de forma explícita, contém mais de 1200 linhas. Tenho corrigido e feito todos os testes passarem em menos de 1 hora (o que tava levando mais de 2 semanas pra eles), porém, com essa tipagem exagerada que tão mais pra warnings, fico em dúvida se ainda vale a pena filar um PR. E esses warnings não afetam em nada ao código da lib. Enfim, parece que TS gera mais problemas do que os resolve, em certas situações

[@noriller]

Um dos problemas é que em um projeto grande, usando interfaces, uma hora vai querer usar o mesmo nome que já foi usado em outro lugar. Dai... você quer usar e vai ver que precisa implementar um monte de coisa aleatória que não precisa só por que foi definido numa interface de mesmo nome em outro lugar. E aquilo de passar o "job" no construtor do tipo... não é só generics?

[@DriwChannel]

A real é que interface não existe para TypeScript, o que existe é só uma formatação, um autocomplete. No Java por exemplo você consegue ver que a interface existe por reflection, no typescript ela se quer vai existir quando virar javascript (.js). Interface é quase uma doc no TypeScript. O BO mesmo é o cara tentar explicar algo sem conhecer o básico do POO, acredito que a intenção dele seria a de tipar um objeto de GET api/... ao invés de usar interface, o objetivo aqui seria transformar o retorno da API em objeto tipado ao invés de objeto anônimo que é a mesma coisa que você faz no "let obj = { ... }" @edit se bobear com os lint da vida você consegue configurar pra não ser possível a interface ser redeclarada, até por que tem coisas que não é o typescript em si, mas sim os lints da vida

[@am4rito]

Quando estava aprendendo a utilizar o angular, que usa o TS sempre achei estranho criarem interfaces dessa maneira

[@FWCODING]

Esse mic é muito bom, da pra ouvir os tuc tuc do teclado bem de leves kk

[@TheMathues123]

lucas montando do canal lucas montano, em typscript frequentemente se usa interface como tipo e vice versa para a mesma função, tipar algo para não ficar como "any". Acredito que por isso o autor fez o post.

[@hallexcosta]

Eu sempre opto por usar interfaces apenas para métodos, e tipos para objetos mais complexos (e como via de regra não defino métodos para tipos apenas utilizo para definir propriedades que levam tipos primitivos ou outros tipos). Não sei se essa é a melhor forma de se usar mais atualmente para mim vem funcionando e consigo ter um controle nítido de quando usar cada uma delas. P.S: Alguns podem estar pensando "E quando você precisa usar uma propriedade de uma classe que implementa uma interface?" Jogo essa responsabilidade para um método getter que será definido dentro da interface e implemento.

[@hallexcosta]

Tirando a parte em que o código pode acabar ficando mais verboso, vocês acham que tem algum outro ponto ruim de seguir por esse lado no uso de tipos e interfaces?

[@keonys1]

Eu prefiro utilizar types pra declaração de funções e objetos que não contenham nenhum comportamento. Dessa forma o LSP me ajuda na hora de chamar essa função me dizendo exatamente o que preciso passar pra ela, não apenas um nada informativo `interface Person` me obrigando a entrar na definição da função

[@PauloPontes]

Incrível como os programadores JavaScript não conhecem os conceitos do que usam.

[@juanelorriagade]

Desanimei com Javascript/Typescript. Recentemente decidi usar Node.js e uma biblioteca chamada whatsapp-js para fazer um bot simples para meu numero do whats (pq não tenho grana para pagar um twilio da vida nem a api oficial no momento). Depois de semanas a biblioteca começou a dar problema, fui atrás de outra e também estava/ está com problema. Fui atrás e descobri que o problema vem da própria versão do Node.js. Consegui corrigir trocando a versão e dois dias após começou a dar erro novamente, agora o erro vem do whatsapp atualizar e a biblioteca ter parado do receber suporte. Obviamente vou corrigir e atrás de solução, mas ficar pra sempre refém de atualização e um terceiro me desanima muito. Tô errado? Com certeza, mas o desânimo é real. Não sinto mais que eu tenha tempo de vida suficiente para ficar estudando e atualizando a cada semana tudo seguindo mudanças do node.js, TS e o que for.

[@Hakunushi]

em typescript as interfaces são implícitas, ou seja, qualquer objeto que contenha as propriedades e métodos da interface mesmo sem implementa-la, serão consideradas válidas para a checagem de tipo, os tipos vão sofrer a mesma inferência. A diferença então está apenas na sintaxe e no fato que tipos não se estendem mas podem na verdade ser compostos com & e |. Como dito, tipos e interfaces não precisam necessariamente serem implementados, basta o objeto sendo inferido se encaixar dentro do tipo ou interface. Mas para mim a diferença crucial é o fato de a interface você poder implementar ela explicitamente em suas classes, deixando mais clara a intuição da classe, enquanto o tipo é apenas implícito oq faz ele mais util para inferência de camadas anêmicas de dados como dtos que carregam dados externos

[@klinsmannlopes8380]

Qual o nome da ferramenta desse quadro ?

[@rawa1off]

aproveita q ta começando no neovim e já faz um vídeo configurando o seu

[@HelderOliveira]

Cara qual site/app é esse de desenho pra fluxo? Achei incrível!

[@gabrielguerra3289]

excalidraw

[@adrianricardoscalia9228]

Aprendi muito isso trabalhando em unity com c# , entendi muito melhor a idea de interface.

[@Diego_oliverira_dev]

meu primeiro trampo era laravel com vue quando vi que nao usava TypeScript no vue fiquei mt feliz kkkkkkk TypeScript e mt chato

[@jhony_tech]

quando vejo typescript no projeto dá até um ruim kkk

[@alamo_DevFlow]

eu já ao contrário. vê um projeto JS sem type me faz querer sair correndo.

[@lucasfelix7788]

​@@alamo_DevFlowAqui também 🤚 Quando vejo um projeto em javascript que não usa typescript, a gastura vem forte 😅

[@henrique_ma]

Chato e polui demais o código, fica uma salada mista

[@alamo_DevFlow]

@@henrique_ma isso eu concordo. mas qualquer projeto em qualquer linguagem quando mais complexo mais poluido a coisa fica... fzr o que. pra ter a segurança de tipos no javascript pra mim vale a pena ter o código poluido.

[@zhunk1831]

Lucas , tu viu a IA que irá concorrer como parlamentar em UK ?

[@murilohasse5694]

public class Cat extended Car @Overwride public void buzina(){ sout("Miau");} Essa é a vibe do autor do artigo

[@mateuscardoso9635]

Claramente você não está habituado ao incrível conceito de gatocarro que é a mais nova moda em París. kkkkkk

[@henriquenas]

eu tenho bastante raivinha de typescript... apesar de ter pago muitos anos de boletos meus, mas depois que eu conheci Dart, não tem como, Dart é muito bem né meu ?

[@pedrohenriqued2231]

Qual aplicação ele usa pra desenhar e escrever aqui? 4:30

[@EdsonSilva-qr5gr]

excalidraw

[@darlonhenrisouza8555]

Eu como dev senior fullstack typescript vou ser sincero Em todos meus projetos grandes tenho regras no Eslint que joga um erro pra caso use o ingerface ao inves do type, a razão na prática é que manter a consistência e o um só padrão na base de código evita muita dor de cabeça, quando preciso usar uma interface eu tenho que colocar um um comentario do eslint desativando a proxima linha, e no meu eslint tem um plugin que me força a justificar todas as regras que eu ignoro por comentários adicionando um contexto ao final do comentário, então ali eu coloco "using interface because ...", mas manter o padrão na base de código toda, seja com interfaces ou com types, pra mim por uma questão de organização do código chegs a ser mais importante do que a parte técnica do uso de intergaces ou type alias

[@matrizoculta]

21:25 nao tankei dksksksk so nao deve ter mais artigos assim pq devem ter dado NaN na hora da postagem

[@pugboladao]

Quais foruns que o Lucas usa para ler esses artigos?

[@emilsonfilho168]

Sou um amador de programação e pretendo futuramente tomar isso como meu trabalho. Já faço alguns códigos e tal mas não consegui acompanhar absolutamente tudo dos conteúdos do vídeo, alguém sabe de algum canto para aprender mais sobre?

[@m__c_s]

interface pra OO (classes e td mais). types pra todo o resto. se n for usar classe acho q mistura conceitos

[@diegovinicius4186]

O maior problema no typescript quanto a types e interface e seu uso, ai o pessoal geralmente quer usar somente uma coisa, entao ou usa types em tudo ou usa interface em tudo, e em sua grande marioria e so para definir como um dado viria de um lado para o outro... algo muito simples para entender quando utilizar, e que interface e utilizado para criacao de novas classes em seu baixo nivel, ja o types deveria ser utilizado para tipar dados que serao navegador pela plataforma, como dtos e afins

[@nennogabriel]

simples... se quer usar interface use o InterfaceScript, mas se está usando TypeScript use types..... precisa colocar tag de hironia?

[@devful_]

Em orientação a objeto eu entendo que no primeiro exemplo do Lucas, continuou como: Lucas é uma Pessoa e Lucas é um Job… ele não deveria ter Job como atributo ao invés de “implementá-lo”? Em OO é importante distinguir a diferença entre ser e ter. Apesar de que no TS, interface permite ser usada para definição de estrutura de “objetos” ao invés de apenas assinaturas de comportamentos

[@silasbispo01]

17:00, Sim, é possível fazer isso com Typescript kkkk injeção de dependencia isso

[@heydevs1494]

05:39 - "Como assim uma pessoa estende um job?" 05:45 - "Eu não sei, eu acho que eu fiquei maluco. Eu só posso tá maluco, cara." Eu ri muito. Kkkkkkkkkkkkkkkkkkkk!

[@Bcostamartins96]

Entendi o artigo do mano. "É difícil pra mim então é um lixo"

[@renanmachado4158]

Jimmy nêutron sem massagem nos palpiteiros 😂😂😂

[@felipebiondes5434]

Nao bugou minha mente, simplesmente faz muito mais sentimento ser assim kk

[@cebolinharenato]

Mas no caso de Typescript na maioria dos casos de uso interface e tipo funciona igual. Você só quer definir quais os campos existem no objeto porque o objeto continua sendo algo dinâmico. Por exemplo você recebe um json de uma api, você só quer definir quais os campos esperados que vai vir nessa resposta tanto usar type como interface funciona igual. Apesar de conceitualmente serem coisas diferentes na prática funcionam como se fosse a mesma coisa por isso existe essa discussão sobre qual é melhor no caso de Typescript.

[@JonatasBuenodoLivramento]

Esse vídeo apesar de muito divertido (parabéns Lucas é sempre muito top seus vídeos) e os comentários irados contra o artigo só existiram por que vocês insistem em tentar olhar para o TS como se ele fosse uma linguagem OO, a única coisa que o TS é, é um Lint que faz o editores de textos terem um autocomplete, para que os bugs voltados a tipos sejam pegos em tempo de desenvolvimento Enquanto isso não entrar nas suas cabeça, vão ficar putos aí com o TS atoa quando comparar com linguagem OO Eu sou puto com o TS mas por outros motivos rs

[@Bruno_Rasq]

É só fazer certo que vai dar certo.

[@rodrigomartins3495]

poderia disponibilizar a sua config fo neovim??

[@azzaax]

q programa é esse q ele usa pra anotar coisas

[@Shaman784]

Droga, achei que era um vídeo contra o TypeScript. Vim correndo. Não vejo a hora de as pessoas perceberem logo que é só não usar TS e pronto.

[@GCoder-sl1sq]

Esse é claramente o mal de uma pessoa que só estudou Typescript no conceito de OOP... triste. Voce esta redondamente correto Lucas trabalho com typescript a alguns anos e é exatamente isso que tu falou.

[@gleitonfranco1260]

Se for UML, a seta vai para a dependência/superclasse/interface

[@felipeols9132]

Vim pelo Mano Deyvin! Recomendação boa demais!

[@MrMatheusssilva]

E eu que piro com o pessoal do Angular usando Interface para tipos concreto, cara, eu penso igual, interface é contrato, tipo concreto é classes que por sinal o JS já tem, será que o TS tentou reinventar a roda?

[@danielguirra1901]

Obrigado Lucas Montano do Canal Lucas Montano, por liberar o almoço.

[@jandersonrodrigues4529]

Qual programa o Lucas tá usando como lousa ?

[@yuribarros5826]

Lombok ajuda muito na criação de getters e setters, ele faz full automático.

[@VanderleiRobertoMoretto]

Estou na "metade" de um sistema relativamente grande usando apenas JS (Node+Express+PostgreSQL) e sinceramente não vi necessidade de usar typeSacrifício, oops, Typescript e nem ORM - 2 coisas muito hypadas! Aah, mas não está 100% em produção, blá, blá, blá Mas duvido que, se caso apareça algo por culpa da "tipagem" , a solução vá demorar mais do que a metade do tempo que eu teria perdido com as amarras do TS!

[@danilohenrique4730]

Eu costumo utilizar Interfaces no TS porque, como no fim das contas ele é apenas um superset do JS, ele é JS. Então os tipos são predominante dados de maneira anônima e fracamente tipada (porque é JS) e apenas obedecem o contrato da Interface, que é o principal ganho dessa bodega de TS Se não é pra usar Interface, uso o JS direto preula Esse cara do artigo ta doidão nos javascrpts

[@devweb7926]

É exatamente isso que tu falou no início do vídeo 😂😂😂

[@juniorzucareli]

Vindo de c# e java, o que eu acho muito esquisito em typescript, é que a galera usa muito interface pra declarar dtos, e o typescript permite isso, não sendo necessário uma classe de implementação daquela interface... Alguém tem alguma explicação pra isso?

[@4nd3rs00n]

acredito que seja simplesmente para ter a abstracao do tipo de dados do DTO tipada(tipo um data class), inclusive tu pode mesclar as interfaces dos dtosInterfaces* para ter um segundo tipo. Se nao precisar de metodo algum no dto pode fazer sentido apenas como estrutura de dados

[@smokwa7341]

Resumo do artigo: Não tem porque usar interface quando você não está trabalhando com POO...mas também não tem porque NÃO usar interface quando você não está trabalhando com POO. No fim, é só mais uma discussão boba de um assunto pouco relevante e que não agrega no seu desenvolvimento :P

[@osilasdev]

Salve Montano!! Tem como liberar os vídeos de GO para os membros não? To afim de maratornar, mas não da só para membros T.T

[@LucasMontano]

Tem vou liberar aqui 👍

[@diegolobo7952]

17:50 "se você não tomar cuidado..." meu amigo, se você não tomar cuidado você está na profissão errada, simples assim.

[@titbarros]

Brother... Tu viajou. Interface no typescript não tem a mesma função de uma linguagem OOP. No fim do dia, nada muda no runtime. Tu confundiu tupla com union. O grande ponto é que a interface pode ser sobrescrita em qq ponto da aplicação. Isso é bom para algumas funcionalidades, mas ruim p uso comum direto em aplicações. Tb tem a questão de ser usada em classes que vc abordou corretamente. No mais dá no mesmo type ou interface. É sim acho uma nomenclatura ruim.

[@chuanigor797]

Alguém sabe me dizer o nome do site que ele utiliza para fazer os desenhos ?

[@micasntna]

Ele só quer ser fancy deixa o cara Lucas kkkkk 😂

[@joaovitor12full]

16:00 Lucas extends Montano

[@phw4865]

Alguem sabe qual app ele esta usando para desenhar ?

[@LorDudugama]

Usa Type em variáveis e usa Interfaces em classes. Um artigo inteiro resumido a isso.

[@meuspequenosvideozinhos9243]

Alguém sabe o programa que é usado no vídeo para criar o diagrama?

[@gabrielaziz3485]

Entendo oque o cara aponta, typescript antes do deno e bun ele trabalhava apenas compilando para javascript que nao é orientado a objeto nativamente, e mesmo agora com classes ainda assim é gambiarrento, com isso concordo que utilizando node é mais seguro a utilizaçao de tipos

[@gabrielaziz3485]

Eu sou programadou ruby on rails, se comentei merda pode fazer uma observaçao ai kk