Smashing Podcast Episódio 26 Com Natalia Tepluhina: O que há de novo no Vue 3.0?

Neste episódio do podcast, estamos falando sobre VueJS. O que há de novo na versão 3.0 e quão difícil será migrar? Drew McLellan conversa com a integrante da equipe principal, Natalia Tepluhina, para descobrir.

Mostrar notas

• VueJS
• O Guia de Migração do Vue 3
• Natália no Twitter
• Site pessoal de Natalia

Atualização semanal

• Diferentes maneiras de criar páginas de produtos digitais
  escrito por Suzanne Scacca
• Teste de unidade em aplicativos nativos de reação
  escrito por Fortune Ikechi
• 5 maneiras como o Google Analytics ajuda os desenvolvedores da Web no design de UI/UX
  escrito por Clara Buenconsejo
• Entendendo os genéricos do TypeScript
  escrito por Jamie Corkhill
• Como usar o movimento do rosto para interagir com a tipografia
  escrito por Edoardo Cavazza

Transcrição

Drew McLellan: Ela é uma desenvolvedora da Web apaixonada, especialista em desenvolvedores do Google e palestrante e autora de conferências. Atualmente ela é uma Staff Front Engineer no GitLab, mas você pode conhecê-la melhor como membro do Vue JS Core Team. Então, claramente, ela conhece o Vue melhor do que quase ninguém. Mas você sabia que uma vez ela ensinou um canguru a cantar. Meus amigos Smashing, por favor, dêem as boas-vindas a Natalia Tepluhina.

Drew: Oi Natalia, tudo bem?

Natalia Tepluhina: Oi Drew, essa foi uma tentativa muito legal de usar meu sobrenome. Preciso dar os créditos. Foi uma das melhores coisas que eu já ouvi de um falante de inglês quando eles tentavam pronunciar meu sobrenome. Acho que não é possível se você não fala russo. A pronúncia correta é Tepluhina, mas é tipo, é por isso que geralmente peço às pessoas que me chamem de Natalia e vamos parar com isso.

Drew: Ok, bem, eu fiz um esforço. Mas a questão importante é, você está Smashing?

Natália: Claro que sim.

Drew: Isso é bom. Então, eu queria falar com vocês hoje sobre algumas novidades realmente empolgantes que teremos em setembro com o lançamento do Vue 3.0. Tem sido um grande lançamento em termos de número de versão, mas é realmente um grande lançamento para o Vue, e está em andamento há algum tempo, não é?

Natália: É. Acho que anunciamos a versão três pela primeira vez em 2018. Acho que foi anunciada na primavera, e o trabalho real começou, quero dizer, as ideias foram na primavera, o trabalho real começou no outono de 2018. E acho que foi anunciado oficialmente na Conferência de Londres, que aconteceu em outubro de 2018. O trabalho ativo levou dois anos. E é muito se você pensar, a versão anterior foi lançada em 2016. Então metade desses quatro anos também foram dedicados ao trabalho do Vue 3.

Drew: Qual foi o tipo de fator de motivação para decidir que uma nova versão principal era necessária? Foi um tipo de decisão consciente de que, ok, vamos trabalhar em uma versão principal, vamos trabalhar no Vue 3, ou foi apenas uma espécie de acúmulo de mudanças que simplesmente exigiram um aumento de versão?

Natalia: Não, acho que foi uma ideia criar uma nova versão devido a algumas coisas muito importantes. Então, em primeiro lugar, havia uma motivação para mudar a reatividade. O anterior foi construído em Object.defineProperty. E tinha algumas ressalvas, todas estão documentadas, mas ainda assim. Você sabe, mesmo se você documentar algo que as pessoas não deveriam fazer, elas farão de qualquer maneira. E você precisaria apontá-los para a documentação. Ninguém lê documentação pelo caminho. Por alguma razão, isso simplesmente acontece. Até você apontar para as pessoas, isso não existe nos documentos, existe. Mas tudo bem. Nós vamos te ensinar de qualquer maneira. Então a reatividade era uma das coisas.

Natalia: O desempenho foi o próximo. O Vue 2 ainda teve e não tem o pior desempenho, mas tivemos algumas ideias sobre como tornar o Vue mais rápido. E também havia um ponto problemático para uma parte específica do nosso público, digamos, pessoas que usam o Vue. Era TypeScript. O Vue 2 foi escrito internamente em Flow, que ainda é fortemente tipado, mas digitar com TypeScript foi um verdadeiro pesadelo, especialmente se você estiver trabalhando com nosso gerenciamento de estado Vuex. Esta foi novamente uma grande parte. E a última foi que perdemos a funcionalidade de abstrair a lógica, em termos não de componentes, mas de partes lógicas compossíveis. Como auxiliares de funções e assim por diante, mas eles também devem poder incluir a atividade do visualizador. Um bom exemplo aqui poderia ser React Hooks, pois eles permitem que você abstraia as partes da funcionalidade e isso claramente estava faltando no Vue. E eu sei que agora soa como “Você roubou o recurso do React”. Não de fato. Acredito que a polinização cruzada de ideias é uma parte grande e agradável do nosso ecossistema e também ajuda os desenvolvedores a alternar entre os favoritos, certo?

Natalia: Então estávamos trabalhando nesses recursos principais para criar o Vue 3 como versão principal.

Drew: Agora, acho que uma das melhores coisas de existir em um ecossistema de código aberto é que há uma riqueza de ideias e experiências de todos os tipos de projetos diferentes, e a capacidade de emprestar essas ideias e emprestar a experiência de outros projetos é realmente benéfico e torna tudo mais forte, não é?

Natália: É. Eu acho que funciona da maneira que chamamos um valor de iteração no GitLab. Quando você tem uma ideia, ela nunca é perfeita. É principalmente como uma coisa muito crua, muito codificada. Talvez mude alguma coisa, mas definitivamente não é perfeito. E você precisa de algumas iterações sobre essa ideia para torná-la realmente boa, nem mesmo perfeita, apenas boa. E acontece com ideias no ecossistema. Alguém surge com uma boa ideia, e você simplesmente a pega e a torna cada vez melhor. E eu aposto que bem, vai ter algo que vai tirar algumas ideias do Vue, talvez eles já tenham pegado algumas ideias do Vue, e o tornem melhor, e não há nada de ruim aqui.

Natalia: Eu sou fortemente contra, tipo, “Você está roubando ideias”. Isso não é roubo, é apenas polinização cruzada.

Drew: Exatamente, sim. Você mencionou que a migração para o TypeScript, então o próprio Vue 3 é escrito usando o TypeScript agora, está correto?

Natália: Sim, sim. E acredite em mim, Drew, eu estava escrevendo a documentação, o pequeno documento sobre como usar Vue com TypeScript. E eu estava tipo, ok, provavelmente de alguma forma como o Vue 2. E eu compliquei tanto o documento que era como digitar tudo explicitamente. Parece bom tudo é digitado. Eu posso ver tipos, então meu ts-link está feliz, até agora tudo bem. E então um de nossos desenvolvedores que estava trabalhando com TypeScript, “Você não precisa fazer isso”. Tipo como, como? “Você não precisa fazer tipos explícitos de dados. Você apenas dá um valor inicial e o ts-link sabe seu número. Já está digitado.” Tipo, como assim? “Removi 90% dos tipos explícitos do documento. Existem apenas duas coisas que você realmente precisa digitar é o proxy do componente, e as propriedades computadas terão. Eles ainda exigem tipos de retorno. Mas o resto é tipo, digitado automaticamente, basta escrever um componente com um método que chamamos de define component. E é isso. Está digitado.”

Natalia: Foi tipo, simplesmente funciona. E para mim, e eu estava trabalhando muito com Angular na minha experiência passada, tenho Síndrome de Estocolmo para TypeScript. Tudo deve ser digitado explicitamente. Quer dizer, se você tiver tipos complexos, é claro que precisará escrever interfaces, mas é assim que o TypeScript funciona. Ainda assim, é muito mais fácil trabalhar com o TypeScript agora com o Vue 3.

Drew: Então isso é ótimo, então é um benefício tanto para o Vue Core Project quanto para os desenvolvedores que estão construindo aplicativos usando Vue, porque eles podem usar o TypeScript em seus aplicativos muito bem com o Vue agora, onde não podiam com o 2.0, bem, qualquer versão de 2.0 tão facilmente. Aqueles que estão familiarizados com a comunidade Vue sabem que o criador do Vue, Evan You, ainda está liderando o projeto de forma muito ativa. Como funciona o Core Team? Como está estruturado quando se trata do processo de desenvolvimento? Não é tudo Evan é?

Natalia: Essa é uma ótima pergunta Drew, porque por anos, literalmente, as pessoas estavam falando sobre Vue como, eu cito isso e vou soar dura, mas desculpe, é como, “Uma estrutura de uma pessoa chinesa, como uma estrutura chinesa mesmo” . E quero dizer, mesmo com o Vue 1.X, já havia uma equipe e havia uma grande equipe por trás do Vue 2 e uma equipe ainda maior por trás do Vue 3. A questão é que todos nós temos responsabilidades diferentes quando falamos sobre Vue.

Natalia: Há pessoas que estão trabalhando no Core, e este não é apenas o próprio Evan, ele está fazendo a maior parte do trabalho no Vue Core, definitivamente, e ele também está liderando o projeto. Mas há pessoas que trabalham no Vue Core, e suas contribuições são absolutamente inestimáveis. E há algumas pessoas novas, juntando-se à equipe Vue também, que trabalham no Core. E também tem times menores trabalhando no ecossistema, tem gente que trabalha no Pure Router, como o Eduardo, tem gente trabalhando no Vue CLI, no Vuex, na documentação também.

Natalia: Há toda uma equipe que trabalha na documentação porque acreditamos que a documentação é importante. E atualmente em nosso site há, acho que 21, 20 ou 21 pessoas, sempre erram a contagem, que pertencem à equipe Core, mas essa não é uma lista estática. Porque nós, obviamente, não estamos contratando, somos uma equipe de código aberto, isso não é trabalho remunerado. Mas acreditamos que se alguém contribui muito para qualquer uma das partes do ecossistema Vue, quando as pessoas já fazem o trabalho do membro da equipe Core, é justo, dando-lhes reconhecimento apenas com acesso aos repositórios e título formal.

Drew: Isso é ótimo porque é um caso em que contribuir para um projeto de código aberto pode realmente compensar um indivíduo. Eles obtêm algum reconhecimento e isso pode ter um impacto na sua carreira profissional e no que você tem.

Drew: Para ouvintes que podem não estar acostumados ao Vue, mas talvez estejam familiarizados com outras estruturas reativas, como você conhece React, Angular e assim por diante. Quais são as grandes mudanças de manchete com o Vue 3 e especificamente quais problemas eles estão tentando resolver? Você mencionou a composição anteriormente como uma dessas coisas, essa é uma das grandes mudanças?

Natalia: Sim, esta é uma das maiores mudanças, e na verdade é uma das coisas que são, antes de tudo, deixe-me fazer uma declaração clara aqui. A API de composição é puramente aditiva. Não é que você precise reescrever seus componentes, você pode adicionar TypeScript a eles. Ou você pode preferir usar toda a sintaxe, agora chamamos de API de opções, e nada mudará para você nesses termos. É como, quando estamos falando de uma nova API, isso não é uma mudança de última hora. Eu só quero enfatizar isso realmente, é muito importante dizer porque quando ela anunciou a API de composição foi um momento terrível.

Natalia: Acho que não descrevemos muito bem as mudanças e fizemos parecer que a compilação padrão será a API de composição. É o nosso mal completamente e as opções eram como, talvez nós o depreciemos em versões futuras, não no Vue 3, claramente. E se houver alguma chance de as pessoas lerem o que você disse errado, elas lerão errado.

Natalia: Imediatamente após esta declaração, foi o RFC onde acabamos de propor a mudança, o Reddit explodiu. O Reddit estava cheio de coisas como: “Oh, meu Deus. Vou precisar escrever tudo. Oh meu Deus. Vue é novo Angular. Eles vão quebrar todas as coisas.” E tinha um cara que criou um artigo no dev.to chamado Vue's Darkest Day. Foi um dia mais sombrio, honestamente. Nós nos sentimos assim, mas eu estava tentando meio que lutar contra isso no meu próprio Twitter como, “Pessoas que não somos realmente… Eles estavam dizendo que começamos a mudar o RFC, acho que Evan começou a mudar o RFC sem anunciar mudanças. Então ele disse: “Vou reescrever isso rapidamente. Vamos empurrar para o mestre”. As pessoas ficaram loucas com isso. Porque eles estavam discutindo sobre certos pontos, então você apenas atualiza uma página e esses pontos não existem mais. Você sente como, eu sou um tolo ou apenas… Que diabos? Quer dizer, estava bem ali. Eu me lembro disso. E acredito que nossa estratégia de comunicação poderia ser melhor e não somos nós.

Natalia: No momento, toda vez que falo sobre composição, isso é puramente aditivo, pessoal. Este é apenas um bom recurso. Você pode usá-lo, você não pode usá-lo, você não é obrigado. Apenas… Existe.

Drew: Qual é o tipo de problema em que alguém pode se meter onde a API de composição é uma coisa nova que os ajuda a sair desse problema? Qual problema está resolvendo?

Natalia: Imagine o componente que tem alguns recursos dentro dele. Digamos que seja pesquisa e classificação. Digamos que procuramos uma determinada lista e tentamos ordená-la. Isso já são dois recursos diferentes e a coisa com componentes Vue é que eles são divididos, com base nas opções, não com base na lógica. Imagine que sua pesquisa provavelmente tenha uma consulta, pois você precisa fazer uma consulta para pesquisar e obter uma matriz de resultados. E estas são duas propriedades reativas. Em termos de seu componente, você os coloca na opção chamada data. E obviamente você precisa de algum método para realizar a classificação. Talvez um clique de botão, talvez outra coisa, algo que execute a pesquisa. Você cria o método. E para classificar você precisa construir algo sobre as opções de classificação, outra propriedade reativa. Em seguida, você executa alguns cálculos para classificar os resultados.

Natalia: No Vue, para isso, você também tem propriedades computadas, que é outra opção. No final, seu componente ficou realmente fragmentado. E imagine que eu sou um desenvolvedor e tenho uma tarefa para trabalhar apenas na parte de pesquisa. Não posso dividir o componente agora, porque esses dois recursos são meio que cruzados em seus caminhos. Procuro alguns resultados e os classifico. E eu preciso pular de dados para método, de método para computado e no final é muito difícil simplesmente mudar o contexto. Especialmente se o componente crescer muito.

Natalia: Que opções tínhamos no Vue 2.0? A primeira opção foi chamada de mixins e mixin é apenas um objeto que pode conter as mesmas propriedades que o componente pode ter e estamos misturando-as com um componente. Parece bom, posso simplesmente mover toda a minha pesquisa para lá e qual é o problema? Existem alguns. Primeiro, isso não é completamente flexível. Se eu quiser procurar um determinado ponto final e movê-lo para o mixin, este será o único ponto final que posso procurar. Mixins não aceitam parâmetros. Eu criei um mixin, é completamente estático. O segundo problema é que o mixin é misturado, o que significa que para certas propriedades isso acontece como uma mesclagem. Por exemplo, se você criou ganchos, eles serão mesclados. Toda a lógica no gancho do ciclo de vida do componente mixin é mesclada. Mas se você tem uma propriedade de dados, uma consulta fria no mixin e por acaso você tem o mesmo no componente, o componente tem prioridade. Ele será substituído. Você não terá avisos. Absolutamente. Isso simplesmente acontecerá e você não terá ideia de que isso aconteceu.

Drew: Todo o escopo está completamente misturado?

Natália: Sim, completamente. Não há chance de você ver e também, mixins são fontes muito obscuras. Você apenas importa o mixin com o nome e coloca para visualizar o mixin da propriedade do componente, é isso. É muito implícito e estou falando sobre isso do ponto de vista da minha própria experiência. Temos uma lógica no GitLab onde um componente contém dois mixins e cada um desses dois mixins contém outro mixin. E aqui vai, aqui está uma propriedade que você precisa verificar e não está no componente. Vamos mais fundo, mixin de primeiro nível. Este não o contém e este também não o contém. Onde está? Você está mergulhando fundo, apenas mais fundo na toca do coelho, apenas para encontrar essa propriedade e o teste também se torna um pesadelo.

Natalia: Mixins são muito, deixe-me dizer, maneiras estúpidas de extrair a lógica. É claro, é claro, é muito fácil de obter. Isso traz muitos problemas se você quiser trabalhar com isso em nível avançado. A próxima maneira de abstrair a lógica no Vue 2.0 foram os componentes sem renderização. No Vue, o componente pode conter um slot. Basicamente uma peça onde você pode colocar qualquer coisa do componente pai. Uma pequena janela, um slot na verdade. E há uma ideia de slots com escopo definido. Imagine que o componente filho que pode expor seu próprio escopo de volta ao conteúdo pai e slot terá acesso a isso. Imagine que eu tenho um componente com slot e o componente executa toda a lógica de busca, digamos busca que tenha um ponto final com parâmetros passados. Nosso componente filho, como pesquisar e, em seguida, expõe essa parte de seu escopo de volta ao pai. Estes são os resultados da pesquisa. Aproveitar. Parece bom. Soa definitivamente melhor do que mixins. Podemos testar parâmetros. A lógica é explícita aqui, estamos retornando algo. Problemas? Existem alguns.

Natalia: Em primeiro lugar, você criou sua instância de componente. Esta não é a operação mais barata do mundo. Segunda parte, é o tempo de execução. O componente só funciona em tempo de execução e isso significa que a propriedade exposta desse componente só será possível no slot que você o expôs como um escopo de slots, portanto, seus resultados de pesquisa estarão disponíveis apenas na pequena parte do seu modelo. Se você quiser brincar com a parte discreta do componente, você não tem acesso lá. É tempo de execução. Não havia como acionar essa lógica se você precisasse de um estado reativo em outro lugar. Claro que ele pode criar um auxiliar como uma função pura e retornar resultados, mas e se eu precisar operar para as propriedades reativas? Foi assim que a API de composição foi criada. Com a API de composição, você pode ter um estado reativo autônomo. O estado reativo não é mais apenas parte do componente. Você pode tornar qualquer objeto ou primitivo reativo. E você pode expô-lo de volta aos pais, é muito explícito.

Natalia: Todas as propriedades que você deseja devolver aos pais estão expostas. É explícito, você pode clicar nele, pode ver onde está, o que é e assim por diante. E a melhor parte, se você incluir a parte da API de composição em um bom componente antigo que possui métodos de dados, propriedades de computador, o que for, simplesmente funciona. Funciona perfeitamente, basta adicionar algumas propriedades e métodos reativos ao seu componente e também pode usá-los com a API de opções antigas.

Drew: Parece que realmente vai ajudar os desenvolvedores a limpar suas bases de código quando se trata de componentes muito complexos ou até mesmo combinações de componentes levemente complexas. E você mencionou a testabilidade de mixins e coisas, a API de composição permite uma melhor testabilidade?

Natalia: Sim, definitivamente porque a API de composição, se excluirmos os ganchos de ciclo de vida disso, porque você também pode executar outro gancho de ciclo de vida no composeable. Na verdade, é pura função. Você tem parâmetros S, está fazendo algo e fora dos ganchos do ciclo de vida ainda há efeitos colaterais. E testar funções puras, como você sabe, é provavelmente a coisa mais fácil. É apenas uma caixa preta, você tem parâmetros S, você tem algo para retornar.

Drew: Isso parece uma solução muito abrangente para um problema que tenho certeza que muitas pessoas que criam aplicativos mais complexos com Vue apreciarão. E certamente parece uma ótima maneira de eliminar o tipo de bug que eu sei que pode aparecer com mixins, onde é muito fácil introduzir bugs, como você mencionou, com o escopo sendo mesclado e todo esse tipo de coisa.

Drew: Eu sempre acho que uma consideração enorme ao escolher construir em cima de uma estrutura é a estabilidade da API ao longo do tempo. Talvez estabilidade não seja a palavra certa, mas acho que muitos de nós foram picados por construir em cima de uma estrutura e depois passar por uma grande reformulação e nos deixar com aplicativos que exigem um grande investimento para migrar ou acabam sendo vinculados para uma versão antiga de uma estrutura que não é mais suportada. É uma situação horrível de se estar. Quanto tempo de sono vou perder ao mover um grande projeto do Vue 2 para o Vue 3?

Natalia: Em primeiro lugar, a superfície da API é 90% a mesma que era. Não tínhamos tantas coisas obsoletas ou filtros obsoletos que podem ser substituídos por hubs de eventos obsoletos. Se você quiser usar um EventEmitter, precisará substituir uma exibição baseada em alguma biblioteca externa também. Essas são grandes mudanças, mas falando sobre migração… Deixe-me esclarecer, estou realmente dividido agora, porque por um lado sou membro do Vue JS Core Team. Por outro lado, sou um engenheiro de equipe no grande projeto que usa Vue. Se você está prestes a iniciar a migração agora, não recomendo fazê-lo. Em primeiro lugar, o ecossistema não foi lançado, quero dizer, se falarmos sobre bibliotecas principais como Pure Router, PUX, Vue CLI, elas estão em boa forma, mas ainda são candidatas a lançamento, não lançamentos. E se falarmos sobre outros ecossistemas, como bibliotecas não principais, talvez, bibliotecas de componentes de interface do usuário, talvez algumas bibliotecas de validação de formulários, eles não estão prontos, principalmente, para o Vue 3. E se você tem um grande projeto, tem tantas dependências que precisa Cuidado. Então isso seria uma coisa complicada.

Natália: Quais são as opções? Você tem um grande projeto, deseja usar toda essa bondade da API de composição. Como conseguir isso? Em primeiro lugar, planejamos lançar uma versão LTS do Vue 2.0, Vue 2.7. Isso incluirá muitos avisos de descontinuação, para que você possa ver o que será descontinuado, como refatorá-lo para não quebrá-lo com o Vue 3. Assim, você ainda estará tecnicamente usando o Vue 2, mas estará preparando o Vue 3 de qualquer maneira porque você tem todos os avisos.

Natalia: Em segundo lugar, usaremos uma ferramenta de migração que será capaz de apenas executá-la e funcionará como um codemod, substituindo coisas relacionadas ao Vue 2 por alternativas ao Vue 3. Claro, nenhum codemod é perfeito. Nosso objetivo é, em primeiro lugar, fazer substituições sempre que possível, mas também mostrar avisos sempre que a depreciação não for facilmente tratada. Codemod será capaz de reconhecer uma coisa e lançar um aviso, mas não substituí-lo por si só. Isso é como um grande plano e no momento em que o Vue 2.7 for lançado e acho que agora a estimativa de chegada deles é dezembro, se bem me lembro, precisaria verificar o roteiro, mas acho que é dezembro.

Natalia: O ecossistema também estará mais ou menos pronto. Se você tem um projeto grande com Vue 2.0, espere um pouco mais até que o Core esteja estabilizado porque mesmo que você produza uma biblioteca perfeita ela ainda precisa de algum tempo para estabilizar porque as pessoas começam a usar isso, as pessoas começam a relatar bugs. Se você está prestes a usá-lo para um projeto de estimação e relatar bugs, por favor, você é muito bem-vindo para fazê-lo. E depois disso, haverá uma boa maneira de migrar para o Vue 3.

Drew: Então a ferramenta de migração que você mencionou parece bem interessante. Isso é basicamente uma ferramenta de análise estática que analisa seu código e…

Natalia: Sim, sim, sim, é um código ou uma ferramenta. No momento, está disponível de forma muito limitada. Está disponível como um plug-in do Vue CLI. Se você tem um projeto baseado em Vue CLI, você pode executar o upgrade do Vue e ver como a ferramenta funciona. Não está na forma que queremos até agora. Infelizmente, não trabalho em um projeto construído em Vue CLI. Eu precisaria esperar e verificar o que está acontecendo mas, por exemplo GitHub, já demos alguns passos mesmo sem ferramenta de migração para preparar, pois sabemos o que está obsoleto. Na verdade, é declarado na documentação do Vue 3.

Natalia: Existe guia de migração. Você pode ver todas as mudanças de última hora e coisas que foram obsoletas e você já pode trabalhar em parte delas mesmo na base de código Vue 2.0. Por exemplo, no Vue 2.6, alteramos a sintaxe dos slots. A sintaxe para slots de escopo foi preterida, mas não negada, ainda existe. Ele dá um aviso, mas você pode executá-lo. E, claro, com uma base de código com sete anos de idade, ninguém se importa em substituir toda a sintaxe obsoleta se ela simplesmente funcionar. Não há nenhum aviso em produção. Os slots funcionam. Em desenvolvimento como, “Oh, vejo algum aviso no console. Talvez 20 deles, tudo bem. É amarelo e não vermelho. Eu não me importo".

Natalia: Você sabe que acontece com todo mundo. Criamos um grande épico para trabalhar nisso. Encontre todos os conjuntos atuais de sintaxe antiga. Fazemos um esforço para substituir nossos EventEmitters, novamente, projeto de sete anos, não nos julguem. Temos EventEmitters. O GitLab estava trabalhando no EventHubs. Substituímos a diversão baseada em Vue por bibliotecas externas. Eu recomendaria fazer o mesmo. Passe pelo guia de migração verificando o que já pode ser substituído e quais alterações você já pode fazer para se preparar e começar a trabalhar nisso.

Drew: Com o estado atual da ferramenta de migração, é uma boa maneira de testar as águas com sua base de código. Basta executá-lo e dar uma olhada para ver o que já sinaliza, para ver se parece bom ou se há algumas coisas grandes ou ainda é imaturo para isso? É melhor esperar até dezembro, quando pode realmente consertar as coisas.

Natalia: Se eu tivesse um grande projeto, não recomendaria fazê-lo. Se você tem um pequeno projeto ruim ou talvez algum projeto pessoal, mas não é tão grande, eu recomendaria executá-lo e verificar problemas como o que você tem, porque para dois projetos de médio porte eu o tenho executado. Acho que um ou dois problemas. Não posso dizer que é imaturo. Já está em boa forma. Mas para grandes projetos novamente, é um legado, são coisas exóticas. Não façam isso na produção, pessoal.

Natalia: Além disso, se você quiser brincar com o scaffolding do seu projeto, agora o Vue CLI suporta dois modos. Você pode criar um projeto Vue 2, você pode criar um projeto Vue 3. E definitivamente experimentá-lo pelo menos. Esta é uma boa maneira para nós também porque enquanto você joga, você descobre bugs, você reporta bugs, nós tentamos corrigi-los e assim por diante.

Drew: Nos documentos e no roteiro de desenvolvimento, vejo menção a uma compilação de migração. Isso é algo diferente do que falamos ou é disso que estamos falando?

Natalia: Não, não, é a mesma coisa. É o mesmo e deve estar pronto, mas por enquanto, se você planeja a migração, o caminho principal é apenas ler os documentos e seguir o que for dito lá, porque definitivamente fazemos um esforço sempre que não temos ferramenta de migração, equipe de documentação foi em frente e criou um guia detalhado do que é a mudança, por que foi feita e o que é realmente uma substituição aqui.

Drew: Sim, nos documentos há um guia de migração bastante abrangente como parte dos documentos do Vue 3 e menciona muitas mudanças que precisam ser migradas. Acho que alguns deles não terão impacto em todos os projetos. Muitos deles eram essencialmente casos extremos para muitas pessoas. Isto é Justo?

Natalia: Sim, uma boa parte deles, por exemplo, filtros, definitivamente são casos extremos, porque mesmo no GitLab com, pela terceira vez, uma base de código de sete anos e uma grande. Tivemos uma ou duas ocorrências de filtros e eles não foram mais utilizados. Foi uma coisa boa que nós os procuramos e os removemos completamente porque tipo, “Oh, código não utilizado” e, novamente, quem se importa, simplesmente existe.

Natalia: Eu diria que mudanças totalmente revolucionárias são as mudanças de modelo. Dê uma olhada nisso porque cada projeto que conheço contém pelo menos um modelo Vue, com certeza. Isso deve ser verificado e talvez os atributos também mudem porque atualmente estamos incluindo classe e estilo, tubulares e éteres. E se você já trabalhou com o Vue, anteriormente ele não era incluído. No momento, a maneira como você passa classe e estilo para componentes filhos é um pouco diferente e eles definitivamente merecem atenção.

Drew: Isso é bom saber. Os lançamentos 3.0 que são lançados com Vue, quero dizer, você mencionou o ecossistema e tudo ao seu redor, Vuex e todas essas outras partes do ecossistema que precisam avançar para esse nível. É por isso que, atualmente, o site, o grande botão “Getting Started” ainda vai para o Vue 2? Parece que o Vue 3 foi lançado, mas não com total confiança. Mas é por causa dessa questão do ecossistema que ainda é assim?

Natalia: Não, acho que você acabou de encontrar um bug, deixe-me verificar rapidamente. Não, começar está apontando para o Vue 3, tudo bem. Quero dizer, se você for ao vuejs.org, ele aponta para a versão dois. Isso é intencional porque planejamos substituí-lo por um subdomínio como o Vue 2, que está em andamento, mas até agora decidimos deixar o vuejs.org onde está e criar o Vue 3 e é por isso que há um banner no vuejs. org. Se você for a qualquer doc-

Drew: Há um banner muito pequeno no topo, sim.

Natalia: Sim, tipo pequeno.

Drew: Sim.

Natalia: Devemos torná-lo maior, eu acho. Maior e com melhor contraste de cor. Meus sentimentos de acessibilidade ficam assim: “Ah, não há nada de contraste aí”.

Drew: Isso é uma boa notícia. Se alguém está começando, talvez não um grande projeto, mas se alguém está começando um projeto pessoal ou querendo aprender Vue, certamente, Vue 3 é o lugar para começar?

Natália: Eu diria que sim. A curva de aprendizado não é tão diferente assim. Como era uma intenção da equipe de documentação ter as opções de sintaxe antigas, não devo dizer antiga, na verdade é a sintaxe atual. A sintaxe familiar como padrão. Porque se você passar pela documentação do Vue 3 você verá com a API de composição apenas em tópicos avançados e o caminho de aprendizado que você tem com o Vue 3 é meio parecido com o que você tinha no Vue 2. Não há grande coisa para começar com um mais novo versão se você está apenas aprendendo Vue e tenta experimentá-lo e acredito que seria um investimento melhor se falarmos sobre carreira. Comece a aprender a versão mais recente porque ela ultrapassará todos os projetos. Eventualmente, talvez meio ano, um ano, mesmo para projetos de grande porte, haverá migração.

Drew: Eu pareço ter em minha carreira pessoal, um talento real de chegar às plataformas no momento em que elas estão no processo de uma grande migração. Quero dizer, até mesmo, você se lembra, Macromedia Director, voltando tão longe e Shockwave, Flash e todo esse tipo de coisa. Cheguei a isso quando eles estavam fazendo a transição para a sintaxe de ponto e tive que aprender os dois. E aqui estou eu, me encontro no último mês, trabalhando em um projeto em Vue pela primeira vez, que é um projeto Vue 2 e aprendendo à medida que prossigo e ansioso por todas as coisas que estão por vir no Vue 3. É certamente um momento interessante para aprender algo à medida que migra, mas parece que não é muito difícil com o Vue e, uma vez que o ecossistema alcançou o Core, devemos estar em um bom lugar.

Natalia: Oh, Drew, eu só quero fazer uma observação sobre o que você disse sobre a imigração de grandes projetos. Você pode me imaginar tipo, 2018 e estou entrando no GitLab. Eu não era membro do Core Team, sou apenas um colaborador neste momento.

Natalia: Imediatamente ao mesmo tempo que Evan disse, “Oh, nós vamos fazer o Vue 3”. Todo mundo gosta, “Sim, legal”. Primavera de 2019 você é o Core Team. Quero dizer, todo o GitLab é como, “Oh, isso é fofo. Todos nós temos migração e você sabe quem é o responsável por isso?” E você pode imaginar como acontece quando você escreve a documentação para o Vue 3, todo mundo estará lendo e sua própria empresa fica tipo, “Oh, eu quero aprender algo sobre o Vue 3, não consigo entender seus documentos”. Então você fica tipo, “Oh, caramba, isso é tão doloroso” porque você é um desenvolvedor lá e um escritor de tecnologia, meio que aqui.

Natalia: Você está no meio disso, mas devo dizer que é muito benéfico para o framework também porque qualquer grande produto criado com um framework é um ótimo campo de batalha para encontrar bugs e trazê-los de volta para a biblioteca, para o ecossistema. Posso dizer que os testes, e o GitLab é de código aberto, Vue Test Utils, que é uma ferramenta de teste para Vue. Uma equipe estava usando nosso código de teste baseado em testes, o que faz muito sentido, certo. Porque você pode encontrar alguns casos de borda e assim por diante. Mas ainda assim, quando penso em migrar o GitLab para o Vue 3, me sinto uma responsabilidade pessoal por isso. Não estou apenas no meio da migração, sou pessoalmente responsável por cada bug que encontrarmos.

Drew: Olhando para a geração anterior de frameworks JavaScript, acho que um dos mais bem-sucedidos foi o jQuery, naquela época, e acho que ganhou força porque tinha uma API extremamente bem projetada. Just this concept of taking a CSS selector and using it to query the DOM in your JavaScript was something that jQuery popularized. And I think that really resonated with hardworking developers who didn't need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it's doing. And if I need to do something I've not done before I can sort of guess at how it would be implemented and usually I'm right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It's changed slightly but we had a concept that was called Documentation Driven Design. And it's a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that's why it's intuitive. If it's easy to explain, people probably will get it on themselves. That's why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don't need to explain what v-if is doing because it's clear, right.

Drew: É mesmo.

Natalia: It's kind of insulting and same with v-else. V-if, v-else-if, v-else and that's it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It's all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn't work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It's so nice to use”. I'm just building the same stuff and it's just been a pleasure. I don't need to think about the tool, I'm thinking about what I'm going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I've been working with Angular from version two to version six on a commercial project and it's a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it's just hard being a developer. And after this, working with Vue is like, “Oh, it's just like a walk in the park”.

Drew: There can be a danger with software that when it's so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that's a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it's better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I'd been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it's easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You're free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it's not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I'm like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it's good and stable and it's developing and it's not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it's actually better for the framework.

Natalia: Last year we introduced the RFC process. It's actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it's not decided, it's not set in stone. We just have an idea and we want to hear what community thinks. I believe it's great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it's true. It's actually shaped by community. It's not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They're not shaping the framework and I believe this is great.

Drew: It's quite telling when you mentioned the list of active Core Team members is 20ish people and they're all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you're at GitLab and there are other people who are just independent consultants and it's not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We're changing direction, we're not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I've spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you're listening to this, the site will have changed and will just be Vue, but that's also where you find the docs and in the docs is that really good migration guide that we mentioned. I've been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I've been learning about Apollo Client version three. It's funny, because if you look at versions and I've been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we're adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you're curious about Apollo Client version three definitely give it a try. It's interesting to see how it's evolving.

Drew: I'm definitely going to give that a try. I've used Apollo on a couple of projects and it's really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.