@@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
"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'"
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
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
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.
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 {}
À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.
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.
"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...
@@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...
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; }
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.
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! 🤷♂
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
Ó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.
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
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.
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
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
@@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
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!
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.
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
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 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
É 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... 😜
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
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
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
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.
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!
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
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
Composition over Inheritance no caso do Job, pois a classe Person deveria ter uma propriedade job que pode ser nula assim: Person { ... job?: Job ... }
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
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.
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
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
@@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.
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.
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.
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?
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
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
Type merge é importante no typescript devido a natureza da linguagem javascript. Por ser a única linguagem que é utilizada NATIVAMENTE nos navegadores ela precisa ser flexível quanto a implementação de suas APIs, por consequência das interfaces. Isso acontece principalmente pela diferença entre as implementações das APIs pelos vendors de navegadores. Eu, por exemplo, precisei estender recentemente uma das interfaces contidas na lib.dom. A interface em questão é a PermissionDescriptor, que possui uma propriedade chamada `name` cujo tipo é PermissionName. Acontece que essa interface não está implementada em todos os navegadores com todos os nomes de permissões possíveis. Então precisei implementar meus próprios tipos para os nomes de permissão e fazer o merge com a interface que fica na lib.dom. Normalmente quando isso é feito utilizamos também uma custom type guard para checar, em runtime, se o tipo especificado é ele mesmo. Lembrando que typescript só existe no código fonte e não é executado no navegador. Então a flexibilidade que o typescript oferece se deve aos fatos de que: navegadores rodam apenas javascript, typescript é utilizado no client/server e vendors de navegadores diferentes podem implementar interfaces diferentes para a mesma API. Então, o principal motivo do typescript ser tão flexível é permitir a extensão sem precisar interferir no código fonte. Sempre que se for falar sobre typescript é importante lembrar que ele NÃO É SERVER FIRST e SIM CLIENT FIRST.
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
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.
Cara, isso me deixava meio puto no TS, mas o que eu faço é: Preciso garantir assinaturas de métodos? Sim, então uso interfcae Quero tipar um objeto / alguma coisa, uso type. Quando devo usar Type? Simples: - Está integrando alguma API e quer tipar o retorno ou dados da requisição - Precisa tipar uma requisição e resposta da sua API - Precisa tipar retorno de dados do seu db Tudo isso vai de Type, caso contrário, ou seja, se o seu propósito é abstração / assinatura de métodos / inversão de controle, vai se interface. Qual a dificuldade disso? 🤣 O problema é que no TS, ambos parecem muito similar, mas tu precisa usar seu cérebro pra usar do modo certo.
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
Types são classes abstratas e Interfaces são interfaces. São parecidos mas conceitos diferentes. Só isso. Você usa cada um para a situação que for mais interessante, não só a nível programação, mas principalmente no nível d arquitetura da plataforma.
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
Problemas artificiais com discussão infinita que só existem quando você é convencido a usar TS. Enquanto TS está chorando sobre o que acha que é errado de algo irrelevante, o JS já entregou a feature com garantia industrial de performance e segurança. Quem precisa de TS é junior corporativo. Type-safety é o maior golpe da última década.
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!
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
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
O pior é que eu não me assusto com essas "loucuras" ditas por "especialistas". O mundo JS sempre foi permeado pelo caos, tipagem dinamicamente fraca é o termo mais lindo que eu já ouvi para estruturação de dados em JS e o pior é que faz total sentido nesse contexto hahaha. Obviamente que para quem vem do mundo Java vai estranhar, o java escrito precisa de uma extensão para ser mais ou menos decente (tu acha que TS é loucura porque tu não avaliou coffescript ainda hahaha)
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
Mano esse vídeo me lembrou daquele meme do carinha tentando encaixar as peças de formatos básicos (estrela, circulo, quadrado) errados nos buracos da base com a frase em cima "Desenvolvemos para ser simples mas o User não sabe usar". Btw, gambiarra dá pra fazer em qualquer paradigma.
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?
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.
Lucas talvez pela falta clara de conhecimento em TypeScript e principalmente falta de experiência em grandes times trabalhando no mesmo projeto usando TS tanto no front como no back, você tenha ficado tão "irritado" com o artigo. A dica que eu dou cara é não opinar sobre o que você não tem experiência. O artigo está bem claro pra quem trabalha com isso diariamente. Fazer pouco caso da tecnologia porque você trabalha com outra é coisa de estagiário punheteiro que acabou de entrar na área - minha opinião. Um abraço.
Eae rhuka kkk, mano se voce é programador, provavelmente ja viu o grafico de conhecimento por confiança, entao suponho que pelo seu comentario infeliz que ou voce é um "estagiario punheteiro", ou o criador do typescript, mas acredito que se fosse bom mesmo noque acha que é, nao estaria perdendo seu tempo aqui, gostaria que voce com seu conhecimento absoluto escrevesse uma postagem talvez no tabnews refutando os pontos abordados por ele que voce discorda, embasando em testes e documentaçoes, assim talvez vc pare de passar vergonha na internet
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!
É sério isso mano? O provável background disso aí é que ele trombou com uma interface na propriedade do componente, e ficou procurando uma sarna pra se coçar, porque os motivos apresentados por ele para não utilizar a interface são ridículos. Sempre uso interface nas propriedades dos meus componentes, isso garante que as propriedades que aquele componente vai receber não se altere. "Ahh mas eu tenho como declarar outra interface com o mesmo nome", mas porque vc quer fazer isso? vá em frente! declare! mas não importe essa interface no componente que tem a interface do mesmo nome , e fim de papo.
O problema é redeclarar uma interface de forma errônea, o que pode acontecer em projetos grandes e desorganizados. É uma baita treta ter uma mesma interface declarada duas vezes (ou até mais?) com tipos incompatíveis. Por este simples motivo, usar Types acaba sendo mais seguro que interfaces, e só por isso. 😅
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?
O Cara escreve um artigo sem saber usar direito, deve ser um Sênior de 6 meses.
Ou gerado por IA 😂
@@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
@@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
traduzido pelo Google
"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'"
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ê.
Python no C# do proximo dev. Ninguem pensou em mim na minha vez.
@@filipeleonelbatista essa foi boa kkk
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
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
@@jbfaneto exato! mas aí que vc começa a melhorar d verdade.
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
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.
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 {}
À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.
Profundo
Pior que é uma boa técnica. Se perguntar, ninguém responde. Se descer o cassete vem uma enxurrada de resposta
5:40 "eu só posso tá ficando maluco" esse é o sentimento
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.
"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...
em go isso fica delicinha, fazer uma composition e ser feliz
Mas os humanos nasceram para trabalhar e apenas isso
interface PersonInterface {
name: string
job: JobInterface
}
essa é a implementação que pra mim deixa da maneira mais clara possível o código
Faria mais sentido Person extends Employee (funcionário)
@@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...
Tu reconhece um javascripto quando ele vem com o papo de "qual é melhor que qual"
Montano tá ficando igual o Vegeta.
Ele está virando o Pica-Pau com esse topete dele.
ahahhaahhaahahhaha
Ele vai ser escalado na continuação de Dragon Ball Evolution
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;
}
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.
eu tbm estava trabalhando assim, mas esse vídeo começou a me fazer questionar se isso é bom kkk
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! 🤷♂
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
Ó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.
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
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.
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
Regra de um typescript, esqueça tudo que aprendeu em POO
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
@@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
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!
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!
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.
22 min aprendendo mais doq aprendi em 1 ano de faculdade, parabéns lucas montano do canal lucas montano
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
não sei se ele gravou sobre esse artigo ou não, talvez… também pego conteúdo do Reddit
prime mentioned
The Name: Lucas Montano do canal Lucas Montano
Como javeiro, não entendo a ideia interfaces com campos 😢 pra mim deveria ser definição de comportamentos públicos
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
Como um c#peiro devo concordar e pra mim em todo momento que ele disse interface eu entendia como classe abstrata
@@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
É 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... 😜
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
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
@typescript-eslint/no-redeclare com ignoreDeclarationMerge
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
Mais um excelente vídeo, gosto muito de ver os vídeos do Montano porque tem sempre uma pequena aula dentro do vídeo.
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.
Muito foda, não tinha parado pra ver esse canal ainda.
Artigo compara chave philips com chave de fenda e o problema de exemplo é qual é melhor usar para pregar um quadro na parede.
Incrível como os programadores JavaScript não conhecem os conceitos do que usam.
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!
public class Cat extended Car
@Overwride
public void buzina(){ sout("Miau");}
Essa é a vibe do autor do artigo
Claramente você não está habituado ao incrível conceito de gatocarro que é a mais nova moda em París. kkkkkk
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
17:06 "Uma pessoa não é o seu trabalho. Tu é muito mais que o seu próprio trabalho" - DO CANAL LUCAS MONTANO, Lucas Montano
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
Composition over Inheritance no caso do Job, pois a classe Person deveria ter uma propriedade job que pode ser nula assim:
Person {
...
job?: Job
...
}
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
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.
Aprendi muito isso trabalhando em unity com c# , entendi muito melhor a idea de interface.
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
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
meu primeiro trampo era laravel com vue quando vi que nao usava TypeScript no vue fiquei mt feliz kkkkkkk TypeScript e mt chato
quando vejo typescript no projeto dá até um ruim kkk
eu já ao contrário. vê um projeto JS sem type me faz querer sair correndo.
@@alamo_DevFlowAqui também 🤚
Quando vejo um projeto em javascript que não usa typescript, a gastura vem forte 😅
Chato e polui demais o código, fica uma salada mista
@@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.
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.
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.
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?
17:06 observe como o Angular trabalha:
export class StatusComponent {
constructor(private data: DataService) {}
}
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
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
Esse mic é muito bom, da pra ouvir os tuc tuc do teclado bem de leves kk
aproveita q ta começando no neovim e já faz um vídeo configurando o seu
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.
Type merge é importante no typescript devido a natureza da linguagem javascript. Por ser a única linguagem que é utilizada NATIVAMENTE nos navegadores ela precisa ser flexível quanto a implementação de suas APIs, por consequência das interfaces. Isso acontece principalmente pela diferença entre as implementações das APIs pelos vendors de navegadores.
Eu, por exemplo, precisei estender recentemente uma das interfaces contidas na lib.dom. A interface em questão é a PermissionDescriptor, que possui uma propriedade chamada `name` cujo tipo é PermissionName. Acontece que essa interface não está implementada em todos os navegadores com todos os nomes de permissões possíveis. Então precisei implementar meus próprios tipos para os nomes de permissão e fazer o merge com a interface que fica na lib.dom. Normalmente quando isso é feito utilizamos também uma custom type guard para checar, em runtime, se o tipo especificado é ele mesmo. Lembrando que typescript só existe no código fonte e não é executado no navegador.
Então a flexibilidade que o typescript oferece se deve aos fatos de que: navegadores rodam apenas javascript, typescript é utilizado no client/server e vendors de navegadores diferentes podem implementar interfaces diferentes para a mesma API. Então, o principal motivo do typescript ser tão flexível é permitir a extensão sem precisar interferir no código fonte. Sempre que se for falar sobre typescript é importante lembrar que ele NÃO É SERVER FIRST e SIM CLIENT FIRST.
Que aplicativo é esse de rascunhos e diagramas que vc usa??
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
Qual software e este q ele usa pra desenhar ?4:55
Quando estava aprendendo a utilizar o angular, que usa o TS sempre achei estranho criarem interfaces dessa maneira
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.
Cara, isso me deixava meio puto no TS, mas o que eu faço é:
Preciso garantir assinaturas de métodos? Sim, então uso interfcae
Quero tipar um objeto / alguma coisa, uso type.
Quando devo usar Type?
Simples:
- Está integrando alguma API e quer tipar o retorno ou dados da requisição
- Precisa tipar uma requisição e resposta da sua API
- Precisa tipar retorno de dados do seu db
Tudo isso vai de Type, caso contrário, ou seja, se o seu propósito é abstração / assinatura de métodos / inversão de controle, vai se interface.
Qual a dificuldade disso? 🤣
O problema é que no TS, ambos parecem muito similar, mas tu precisa usar seu cérebro pra usar do modo certo.
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
Types são classes abstratas e Interfaces são interfaces. São parecidos mas conceitos diferentes. Só isso. Você usa cada um para a situação que for mais interessante, não só a nível programação, mas principalmente no nível d arquitetura da plataforma.
Nao bugou minha mente, simplesmente faz muito mais sentimento ser assim kk
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
É só fazer certo que vai dar certo.
Usa Type em variáveis e usa Interfaces em classes. Um artigo inteiro resumido a isso.
Lombok ajuda muito na criação de getters e setters, ele faz full automático.
Vim pelo Mano Deyvin! Recomendação boa demais!
Problemas artificiais com discussão infinita que só existem quando você é convencido a usar TS. Enquanto TS está chorando sobre o que acha que é errado de algo irrelevante, o JS já entregou a feature com garantia industrial de performance e segurança. Quem precisa de TS é junior corporativo. Type-safety é o maior golpe da última década.
Dev Typescript curioso pra saber aonde esse artigo quer chegar
👇
O autor leu o artigo do Matt Pocock sobre o uso de Types e Interfaces e ficou emocionado.
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!
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
17:00, Sim, é possível fazer isso com Typescript kkkk injeção de dependencia isso
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
interface pra OO (classes e td mais). types pra todo o resto.
se n for usar classe acho q mistura conceitos
17:50 "se você não tomar cuidado..." meu amigo, se você não tomar cuidado você está na profissão errada, simples assim.
O pior é que eu não me assusto com essas "loucuras" ditas por "especialistas". O mundo JS sempre foi permeado pelo caos, tipagem dinamicamente fraca é o termo mais lindo que eu já ouvi para estruturação de dados em JS e o pior é que faz total sentido nesse contexto hahaha. Obviamente que para quem vem do mundo Java vai estranhar, o java escrito precisa de uma extensão para ser mais ou menos decente (tu acha que TS é loucura porque tu não avaliou coffescript ainda hahaha)
Entendi o artigo do mano. "É difícil pra mim então é um lixo"
Tive uma evolução como programador, ainda sou estudante e posso dizer que eu quase entendi esse vídeo. Kkkkk
É exatamente isso que tu falou no início do vídeo 😂😂😂
Concordo contigo. Mostra pouca fundamentação em OOP.
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
Eu sou programadou ruby on rails, se comentei merda pode fazer uma observaçao ai kk
Mano esse vídeo me lembrou daquele meme do carinha tentando encaixar as peças de formatos básicos (estrela, circulo, quadrado) errados nos buracos da base com a frase em cima "Desenvolvemos para ser simples mas o User não sabe usar". Btw, gambiarra dá pra fazer em qualquer paradigma.
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?
O erro é usar TypeScript. Sempre prefirar depender do que extender.
Obrigado Lucas Montano do Canal Lucas Montano, por liberar o almoço.
Lucas , tu viu a IA que irá concorrer como parlamentar em UK ?
Esse vídeo foi incrível kkkkkkkkkkkk
TypeScript é o que você usa pra evitar os erros que você não teria se não usasse TypeScript
Louco mesmo é pensar que um LLM pode ser treinado com esse artigo ai haha
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.
Lucas talvez pela falta clara de conhecimento em TypeScript e principalmente falta de experiência em grandes times trabalhando no mesmo projeto usando TS tanto no front como no back, você tenha ficado tão "irritado" com o artigo. A dica que eu dou cara é não opinar sobre o que você não tem experiência. O artigo está bem claro pra quem trabalha com isso diariamente. Fazer pouco caso da tecnologia porque você trabalha com outra é coisa de estagiário punheteiro que acabou de entrar na área - minha opinião. Um abraço.
Eae rhuka kkk, mano se voce é programador, provavelmente ja viu o grafico de conhecimento por confiança, entao suponho que pelo seu comentario infeliz que ou voce é um "estagiario punheteiro", ou o criador do typescript, mas acredito que se fosse bom mesmo noque acha que é, nao estaria perdendo seu tempo aqui, gostaria que voce com seu conhecimento absoluto escrevesse uma postagem talvez no tabnews refutando os pontos abordados por ele que voce discorda, embasando em testes e documentaçoes, assim talvez vc pare de passar vergonha na internet
Cara qual site/app é esse de desenho pra fluxo? Achei incrível!
excalidraw
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!
Se for UML, a seta vai para a dependência/superclasse/interface
O negócio é usar Zod
É sério isso mano?
O provável background disso aí é que ele trombou com uma interface na propriedade do componente, e ficou procurando uma sarna pra se coçar, porque os motivos apresentados por ele para não utilizar a interface são ridículos.
Sempre uso interface nas propriedades dos meus componentes, isso garante que as propriedades que aquele componente vai receber não se altere. "Ahh mas eu tenho como declarar outra interface com o mesmo nome", mas porque vc quer fazer isso? vá em frente! declare! mas não importe essa interface no componente que tem a interface do mesmo nome , e fim de papo.
O problema é redeclarar uma interface de forma errônea, o que pode acontecer em projetos grandes e desorganizados.
É uma baita treta ter uma mesma interface declarada duas vezes (ou até mais?) com tipos incompatíveis.
Por este simples motivo, usar Types acaba sendo mais seguro que interfaces, e só por isso. 😅
O erro do Lucas foi esperar POO de um dev js/ts KKKKKK
POO de JS é POO ao pé da letra. E POO de verdade deveria se chamar programação orientada a classes e instâncias.
Lucas Montano tá quase virando o PrimeAge hehehe
The Name: Lucas montano do canal Lucas montano
21:25 nao tankei dksksksk so nao deve ter mais artigos assim pq devem ter dado NaN na hora da postagem
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?
Em TS eu vejo mais problemas em usar interfaces quando deveriam ser classes do que com types.