DEV Community: Emanuel Gonçalves

Teste seus componentes com Vue Test Utils

Emanuel Gonçalves — Fri, 10 Sep 2021 12:37:46 +0000

Fala! Hoje gostaria de trazer o assunto de testes com Vue.js. Depois de alguns meses trabalhando na criação de uma biblioteca de componentes de maneira intensiva, e agora, trabalhando na migração do produto principal aqui da empresa, gostaria de compartilhar alguns pensamentos e opiniões a respeito de algumas abordagens de testes com Vue.js e o uso de bibliotecas que nos auxiliam na hora de implementá-los.

O objetivo é poder discutir o uso do Vue Test Utils e do Vue Testing Library, vantagens e desvantagens de usar um ou outro e quem sabe, num terceiro momento, trazer o uso do Cypress Component Testing, que promete bastante.

Antes de mais nada, você precisa saber que os códigos deste post estarão neste repositório no Github - vue2-testing-blog. Dá aquela força dando um star no projeto e compartilhando.

Sem mais delongas, vamos ao conteúdo de hoje. Como testar nossos componentes Vue.js com Vue Test Utils!

Primeiramente, vou pular a parte da instalação do Vue Test Utils (daqui para a frente vou chamá-lo de VTU), pois normalmente se você inicia um projeto com o Vue CLI e escolhe entre as opções, que irá ter testes unitários, você vai perceber que este pacote será instalado por padrão. Porém, caso você precise de um guia para a instalação, você pode conferir a seção "Instalação" na documentação oficial.

Conhecendo um pouco do VTU

Quando vamos testar nossos componentes Vue.js, precisamos, ao menos, executar duas tarefas:

Buscar elementos dentro do componente
Interagir com esses elementos

Essas duas tarefas acima tem como objetivo testar se, dado uma interação com um componente, ele executa o que a gente espera dele. Vamos a um exemplo extraído da documentação do VTU

// nosso componente Counter
const Counter = {
  template: `
    <div>
      <button @click="count++">Add up</button>
      <p>Total clicks: {{ count }}</p>
    </div>
  `,
  data() {
    return { count: 0 }
  }
}

// nossa suíte de testes
test('increments counter value on click', async () => {
  const wrapper = mount(Counter)

  // busca elementos para interação
  const button = wrapper.find('button')
  const text = wrapper.find('p')

  // executa uma asserção para ter um valor inicial
  expect(text.text()).toContain('Total clicks: 0')

  // interage com um elemento
  await button.trigger('click')

  // testa se ocorre o resultado esperado
  expect(text.text()).toContain('Total clicks: 1')
})

Como você pode ver, executamos as duas tarefas e assim testamos o nosso componente de maneira satisfatória.

Você pode encontrar mais informações sobre essa biblioteca no seu site oficial e encontrar um conjunto de boas práticas no Vue Testing Handbook, criado pelo autor do VTU.

Depois dessa breve introdução, gostaria de compartilhar um pouco das minhas reflexões com relação à essa biblioteca. Já gostaria de adiantar que são minhas opiniões depois de algum tempo usando bastante ela, seja no contexto de uma biblioteca de componentes, seja no contexto de uma aplicação real em construção.

Biblioteca oficial para testes

Uma das coisas que mais incomodam quando vamos usar bibliotecas, plugins ou qualquer outra coisa em conjunto com nosso framework e estamos num processo de migração deste é o suporte que tais pacotes de terceiros irão ter com o framework que estamos utilizando.

Sem dúvida, uma das melhores partes de se usar o VTU é que você vai estar usando uma ferramenta que é mantida pelo core team do Vue.js. Isso significa que qualquer alteração no Vue.js terá impactos e "rapidamente" será propagado para o VTU.

Interação com o componente a baixo nível

Aqui vem uma questão polêmica: o que seria um teste unitário no contexto de aplicações componentizadas que temos hoje em dia? Seria testar uma funcionalidade específica do meu sistema? Seria testar apenas um componente específico, isoladamente?

Se sua resposta a última pergunta foi sim, o VTU é perfeito para você. Ao usarmos a função mount, ela retorna uma instância de um componente, e assim podemos fazer um genuíno teste unitário caixa branca, pois podemos trabalhar com um componente a baixo nível e testar seu comportamento esperado nos mínimos detalhes.

Mas, o que eu quero dizer com trabalhar com um componente no baixo nível?

Se lembra que eu comentei que a função mount retorna uma instância do componente? Por essa instância, eu tenho acesso as propriedades do meu componente (data, computeds e props), bem como aos métodos dele. Sendo assim, imagine que meu componente tenha a seguinte estrutura:

// omitindo o template de propósito
export default {
  data: () => ({
    model: {
      name: null,
      last_name: null,
      position: null
    }
  }),

  computed: {
    canSave () {
      return (
        this.isNotEmpty(this.model.name) &&
        this.isNotEmpty(this.model.last_name) &&
        this.isNotEmpty(this.model.position)
      )
    }
  },

  methods: {
    isNotEmpty (value) {
      if (typeof value === 'string') {
        return value.length > 0
      }

      return value !== null
    }
  }
}

Agora eu quero testar que, se eu alterar o model.name, e o model.last_name, a computed canSave ainda precisa ser false, pois ainda não tenho um valor para model.position. E eu consigo fazer isso sem muito esforço:

// ignorando importação e montagem do componente
it('should keep the canSave computed as false even if name and last_name are filled', () => {
  wrapper.vm.model.name = 'John'
  wrapper.vm.model.last_name = 'Doe'

  expect(wrapper.vm.canSave).toBe(false)
})

Eu também posso testar separadamente meu método isNotEmpty:

it('should return the correct values for the vm.isNotEmpty() method', () => {
  const wrapper = mount(Form)

  expect(wrapper.vm.isNotEmpty('')).toBe(false)
  expect(wrapper.vm.isNotEmpty(null)).toBe(false)
  expect(wrapper.vm.isNotEmpty('test')).toBe(true)
})

Como consequência dessa interação a baixo nível, eu posso não testar a interação do meu usuário com o componente que eu estou testando. Um exemplo: imagine que você tem um componente de login que possui um método login (bem criativo 😅). Você pode testar o método login separadamente. Porém, eu acredito ser melhor testar a interação do usuário com esse método, por exemplo, testando se ao clicar no botão de Login, o método login é chamado e executa a chamada à API com os parâmetros esperados.

Uma outra consequência dessa interação a baixo nível é que se torna um pouco complexo usar o VTU para realizar buscas por elementos dentro do componente.

Pegue como exemplo, este simples componente de formulário. Imagine que eu precise testar o preenchimento de cada campo do formulário e ao final, precise clicar no botão de Salvar e esperar que o componente emita o que espero dele.

Imaginou? Uma possível solução seria essa:

it('should properly fill the model data', async () => {
  const wrapper = mount(Form)

  const name = 'John'
  const lastName = 'Doe'
  const expectedModel = {
    name,
    last_name: lastName,
    position: 'front'
  }

  await wrapper.find('[data-testid="form-name"] input').setValue(name)

  await wrapper
    .find('[data-testid="form-last_name"] input')
    .setValue(lastName)

  await wrapper
    .find('[data-testid="form-position"] select')
    .findAll('option')
    .at(0)
    .setSelected()

  expect(wrapper.vm.model).toEqual(expectedModel)

  await wrapper.find('[data-testid="btn-save"]').trigger('click')

  expect(wrapper.emitted('save')[0][0]).toEqual(expectedModel)
})

Aqui eu uso data-testids - uma boa prática para desacoplar seus testes do código em si - para facilitar essa busca, porém, este problema nos leva a pelo menos dois pontos negativos ao usarmos o VTU.

Não é fluído testar componentes complexos

Uma das minhas maiores dores com o VTU é buscar os elementos para interação, porém, eu preciso reconhecer que isso é uma característica da biblioteca. Ao mesmo tempo que é fácil buscar um componente filho na minha instância e interagir com ele, meu código de teste fica verboso e bastante acoplado à implementação.

Em outras palavras, eu só tenho duas possibilidades de buscar elementos no meu componente: usando um seletor HTML (método find e afins) ou buscando pelo componente em si (usando o método findComponent e afins).

Porém, você talvez concorde que estar acoplado a implementação neste caso não é ruim, na verdade é esperado, pois como estou testando "unitariamente" meu componente, é esperado que eu saiba nos mínimos detalhes como ele funciona, e queira garantir através dos testes seu funcionamento.

É difícil testar acessibilidade

Não é impossível verificar questões de acessibilidade quando usamos o VTU, porém, a biblioteca não encoraja uma abordagem de testes unitários/de integração que ao mesmo tempo, testem questões de acessibilidade.

Um exemplo de teste de acessibilidade é verificar se os meus itens de formulários estão devidamente "rotulados", ou seja, se existem labels que os identificam. Com VTU isso é um pouco complexo. Eu precisaria saber o id de cada elemento, e verificar se existe uma label com o correspondente atributo for.

Em um outro momento veremos que existe uma outra biblioteca de testes que provê uma série de queries que trazem fluidez na hora que estamos criando nossos testes, e ao mesmo tempo, encoraja em pensarmos um pouco sobre acessibilidade na criação de nossos componentes.

Resumindo

Se você está a procura de uma biblioteca de auxílio nos testes unitários dos seus componente Vue.js, sem dúvida, o VTU é uma excelente alternativa, pois ele te dará um controle refinado para a criação dos seus testes.

Todavia, é necessário deixar claro que caso o seu componente seja um pouco complexo e tenha interações com outros componentes, será um pouco trabalhoso criar seus testes com o VTU.

Aonde se aprofundar mais?

A documentação do VTU é sucinta e direta ao ponto, comece por ela.
Se está a procura de uma abordagem mais "mão na massa", não deixe de conferir o Handbook do VTU, que traz alguns cases e algumas boas práticas na criação de testes com o VTU.
Nas minhas pesquisas eu encontrei este Cheatsheet que achei bem interessante. Pode servir como uma referência.

Espero que este post tenha sido útil para você e que ele possa ter trazido algumas reflexões a respeito dessa excelente biblioteca de testes com Vue.js.

Até a próxima.

Conheça o que são as siglas CSR, SSR e SSG

Emanuel Gonçalves — Fri, 27 Aug 2021 12:26:52 +0000

Quando falamos de Nuxt, Next e outras ferramentas, geralmente encontramos algumas siglas difíceis de entender num primeiro momento: CSR, SSG e SSR. E juntamente com elas, surgem alguns questionamentos: Qual a diferença entre renderizar minha aplicação no lado do cliente ou no lado do servidor? Por qual motivo, geralmente, é recomendado eu fazer o uso da pré-renderização?

O objetivo deste post é explicar os conceitos de Client Side Rendering (CSR), Static Site Generation (SSG) e Server Side Rendering (SSR) elucidando tais questões, apresentando suas vantagens e desvantagens e alguns casos de uso.

Antes de entrarmos nos conceitos, segue abaixo uma pequena relação de algumas ferramentas no mercado para a implementação destas técnicas em seu framework de escolha:

Angular Universal - ecossistema Angular
Next - ecossistema React
Nuxt - ecossistema Vue.js
Sapper - ecossistema Svelte

Client-Side Rendering (CSR)

É um formato de renderização em que a parte de renderização do conteúdo é feito no lado do cliente (browser). A tecnologia que mais utiliza esta técnica é a Single Page Application. Neste formato, o servidor é responsável apenas por entregar os assets necessários para a aplicação, mas o HTML não é servido com o seu conteúdo preenchido. Isso fica a cargo do browser.

Toda SPA faz o trabalho de renderização no lado do cliente, mas nem toda aplicação que faz esse trabalho é uma SPA. Explico: antigamente, era comum o uso da técnica AJAX para a requisição de informações do servidor e exibição dessas mesmas informações para o cliente. Como essas informações eram exibidas? Através de manipulação do DOM, seja com jQuery ou outra biblioteca. O ponto é: tais aplicações não eram uma SPA (principalmente porque o roteamento da aplicação ainda era no servidor), apesar de executarem um trabalho de renderização no lado do cliente.

Para saber mais sobre SPAs, confira o post Single Page Applications: Onde vivem e o que comem escrito por [Vinicius Reis]

Server-Side Rendering (SSR)

É um formato de renderização de páginas já bastante conhecido. Como o nome diz, é uma renderização do lado do servidor. Desta forma, haverá a necessidade de uma estrutura no servidor responsável não apenas por servir os assets, mas também por gerar as páginas HTML já completas, com o conteúdo populado. As ferramentas citadas possuem em seu core tal funcionalidade, geralmente com um servidor em Node.js.

Quais problemas o SSR resolve?

Primeiramente, questões relacionadas a SEO (Search Engine Optimization). Como numa SPA a renderização é feita no browser, e alguns web crawlers não tem capacidade de executar código JavaScript, apenas HTML, o web crawler captura uma página com praticamente nenhuma informação semântica, o que é ruim para o SEO.

Segundo, há as questões relacionadas a performance. Uma página com o HTML com o conteúdo necessário já servido é bem melhor do que você ter este mesmo conteúdo em um JavaScript que será baixado, parseado e executado em um momento posterior. Não só isso, em um contexto em que as pessoas usam mais os seus smartphones do que seus computadores para ter acesso a informação na internet, ter uma menor quantidade de código JavaScript é melhor. Lembre-se: performance também é uma métrica para a experiência do usuário.

Porém, o SSR possui um questão na sua implementação: ele exige um servidor que execute a sua aplicação e sirva o código HTML. Atualmente, existem inúmeras formas gratuitas para se fazer isso, com um certo limite, como no caso da Vercel.

Static Site Generation (SSG)

Você pode encontrar este mesmo conceito como pré-render.

É um formato de renderização em que as páginas da aplicação são renderizadas na fase de build da aplicação e com isso, é possível usar qualquer servidor de páginas estáticas (Vercel, Netlify, Github Pages...) para disponibilizar seu conteúdo.

Existem algumas ferramentas que são focados nesse tipo de formato, como o Gatsby para o React e o Gridsome para Vue.js.

A performance, neste formato, é superior ao do SSR pelo fato de que não há um trabalho de renderização das páginas por demanda em algum servidor. Todas as páginas HTML da sua aplicação já foram populadas com as informações necessárias.

Porém, há uma ressalva a ser feita: o tempo de build. Em algumas aplicações, geralmente blogs, há uma quantidade enorme de conteúdo. Dessa forma, se toda a alteração feita em uma página exigir que todas as outras páginas sejam novamente geradas, isso leva a aumento no tempo de build. O Gatsby, por exemplo, já possui uma solução para esse problema através de builds incrementais.

É possível combinar estas técnicas?

Sim, e geralmente se você está usando o Nuxt ou Next, você já combina elas. Por exemplo, com o SSG no Nuxt, ao acessar a primeira página, toda a navegação e renderização continuará seguindo pelo lado do cliente. Isso é positivo pelo fato de que não será necessário, uma vez carregado o site, buscar por novas páginas no servidor.

Um outro caso de combinação é usando o Next, em que é possível ter uma renderização híbrida da página, com partes dela sendo pré-renderizadas e outras sendo renderizadas no browser. Ou ainda, no mesmo projeto, possuir páginas pré-renderizadas e outras renderizadas no servidor.

Qual escolher?

Depende do seu objetivo e propósito. Geralmente, para sites de conteúdo como blogs, uma pré-renderização das páginas (SSG) pode ser uma boa escolha por questões de SEO e performance, haja vista que o conteúdo não muda com muita frequência. Em casos de aplicações complexas, geralmente tem-se optado pelo uso de SPAs, e consequentemente de CSG, também por questões de performance.

Conclusão

Espero que este texto possa ter servido para esclarecer suas dúvida. Se possui algum comentário, não deixe de fazê-lo. Até a próxima!

Para saber mais sobre o assunto:

Grid para layout, flexbox para componentes

Emanuel Gonçalves — Fri, 26 Jun 2020 12:34:17 +0000

Imagem de fundo por Halacious on Unsplash

Compartilho com você a tradução autorizada deste excelente artigo escrito por Ahmad Shadeed.

Título original - Grid for layout, Flexbox for components

Meu irmão é recém-formado em engenharia da computação e ele está atualmente finalizando seu estágio em desenvolvimento front-end. Ele aprendeu sobre CSS grid e flexbox, mas eu notei um padrão que eu vi muito na web. Ele não conseguia decidir quando usar grid ou flexbox. Por exemplo, ele usou CSS grid para fazer o layout do cabeçalho de um site e mencionou que o processo não foi tranquilo, pois ele brincava com a propriedade grid-column e tentava ajustá-la até se parecer com o design.

Para ser sincero, não gosto disso, e também pesquisei sobre um recurso que ele pode usar para aprender as diferenças entre grid e flexbox, com exemplos de ambos, mas não consegui encontrar nenhum. Decidi escrever um artigo profundo que cubra tudo sobre aquele tópico. Espero que você ache claro!

Introdução

Antes de entrar de cabeça nos conceitos e exemplos, eu quero me certificar que você entende a diferença entre CSS grid e flexbox. CSS grid é um módulo multi-dimensional de layout, que significa que ele possui colunas e linhas. Flexbox pode dispor seus itens filhos como colunas ou linhas, mas não ambos.

Se você não conhece CSS grid e flexbox, eu recomendo ler este artigo visual. Se você os conhece, que legal, vamos mergulhar nas diferenças entre eles e quando usar cada um e o porquê.

A diferença entre Grid e Flexbox

Deixe-me ser claro a respeito disso, não há uma maneira direta de decidir entre CSS grid e flexbox. Além disso, não há uma forma correta e incorretá de usá-los. Este artigo é um tipo de guia que recomenda usar uma técnica para um específico caso de uso. Eu explicarei o conceito geral, e então ir aos exemplos, e o resto é você que explora e experimenta mais.

/* Flexbox wrapper */
.wrapper {
  display: flex;
}

/* Grid wrapper */
.wrapper {
  display: grid;
  grid-template-columns: 2fr 1fr;
  grid-gap: 16px;
}

Você notou alguma coisa? O Flexbox apresenta uma lista in-line de elementos, enquanto o CSS grid os torna os transforma em um grid de colunas e linhas. Flexbox está alinhando o alinhamento em uma linha. Isso pode ser uma coluna, se quisermos.

/* Flexbox wrapper */
.wrapper {
  display: flex;
  flex-direction: column;
}

Como decidir qual usar

Decidir entre CSS grid e flexbox pode ser um pouco difícil (às vezes), especialmente se você é novo em CSS. Eu posso ouvir você! Aqui estão algumas perguntas iniciais que eu faço ao escolher entre eles:

Como os itens filho do componente são exibidos? Em linha ou em colunas e linhas?
Como o componente deve funcionar em diferentes tamanhos de tela?

Na maioria das vezes, se o componente que você está vendo tiver todos os itens filhos exibidos em linha, provavelmente o flexbox é a melhor solução. Considere o seguinte exemplo:

Contudo, se você ver colunas e linhas, o CSS grid é a solução para o seu caso.

Agora que expliquei a principal diferença entre eles, passemos a exemplos mais específicos e vejamos como decidir.

Casos de uso e exemplos

Na seção a seguir, discutirei em detalhes sobre os diferentes casos de uso para flexbox e grid.

CSS Grid

Main e Sidebar

Quando você tem uma barra lateral e seção principal (main), o CSS Grid é uma solução perfeita para construí-los. Considere a seguinte modelo:

Aqui está como eu faria isso em CSS:

<div class="wrapper">
  <aside>Sidebar</aside>
  <main>Main</main>
</div>

@media (min-width: 800px) {
  .wrapper {
    display: grid;
    grid-template-columns: 200px 1fr;
    grid-gap: 16px;
  }

  aside {
    align-self: start;
  }
}

Se align-self não for usado para o elemento aside, a altura dele será igual ao do elemento main, não importa o tamanho do conteúdo.

Cards em Grid

Conforme discutido no início do artigo, o CSS grid é auto-explicativo a partir do nome, portanto, usá-lo para criar uma grade de cartões é um uso perfeito dele.

Aqui está como eu implementaria o layout:

.wrapper {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
  grid-gap: 16px;
}

A largura da coluna será de pelo menos 200px, e se o espaço não for suficiente, ele irá colocar os cards em uma nova linha. Vale ressaltar que o código acima pode causar rolagem horizontal se a largura do viewport for menor que 200px.

Uma solução simples é adicionar a definição de grid somente quando a largura do viewport for suficiente. Veja abaixo:

@media (min-width: 800px) {
  .wrapper {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
    grid-gap: 16px;
  }
}

Layout de seção

No design a seguir, podemos usar o grid duas vezes, o primeiro uso é dividir a área em outras duas áreas (a barra lateral "Contact us", e o formulário) e o segundo uso é no próprio grid do formulário.

Não consigo enfatizar o quanto CSS grid é perfeito para isso. Aqui está como fazer no CSS:

@media (min-width: 800px) {
  .wrapper {
    display: grid;
    grid-template-columns: 200px 1fr;
  }

  .form-wrapper {
    display: grid;
    grid-template-columns: 1fr 1fr;
    grid-gap: 16px;
  }

  .form-message,
  .form-button {
    grid-column: 1 / 3; /* deixe que eles tomem toda a largura */
  }
}

Este exemplo é emprestado do meu artigo na Envanto sobre a construção de layouts para formulários web com CSS grid. Eu recomendo que você leia.

CSS Flexbox

Navegação do website

90% das vezes, a navegação do website deverá ser feita com Flexbox. O padrão mais comum é ter a logo à esquerda e a navegação à direita. Isso é perfeito para flexbox.

No exemplo acima, tudo que você precisa definir é o seguinte:

.site-header {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-between;
}

O mesmo conceito também pode funcionar no seguinte design também.

Note como a estrutura de navegação ficou um pouco diferente, mas o espaçamento entre os itens ainda é feito com a propriedade justify-content.

Lista de ações

Quando você ouve falar de uma lista, a primeira coisa que você pensa é uma lista vertical. No entanto, uma lista pode ser exibida em linha, então eu só queria ter certeza de que isso está claro.

Um exemplo de uma lista de ações é algo que podemos pegar emprestado do Facebook ou Twitter. A lista de ações consiste em botões de ação que o usuário pode executar. Veja as imagens abaixo:

Como você vê, os itens são exibidos um ao lado do outro e são distribuídos horizontalmente. Flexbox é perfeito para isso! Esse é um dos principais usos dele.

.actions-list {
  display: flex;
}

.actions-list__item {
  flex: 1; /* expande os items para que tomem todo o espaço disponível igualmente entre eles */
}

Outra variação disso é um botão de ação de uma modal ou um cabeçalho de uma modal.

Tanto o cabeçalho da modal como o rodapé têm elementos filhos que são exibidos em linha. Como você vê, o espaçamento entre eles é feito como abaixo.

Para o cabeçalho da modal, fica assim:

.modal-header {
  display: flex;
  justify-content: space-between;
}

E para o rodapé, é um pouco diferente. A ação "Cancel" usa uma margem automática para se empurrar para a direita. Eu escrevi um artigo detalhado sobre isso.

.cancel__action {
  margin-left: auto;
}

O nome da classe .cancel__action pode não ser perfeito aqui, mas não quero entrar em convenções de nomenclatura de CSS para este artigo.

Elementos de formulário

Uma combinação de um input com um botão ao lado é um caso de uso perfeito para o Flexbox. Considere a figura abaixo:

No primeiro formulário, o input está ocupando todo o espaço restante, fazendo com que ele tenha uma largura dinâmica. O mesmo se aplica ao segundo formulário (Facebook Messenger), o campo de texto ocupa todo o espaço restante. Vamos olhar mais de perto.

.input { flex: 1 1 auto; }

Observe que, sem usar flex: 1 1 auto no campo de texto, ele não se expandirá e preencherá o espaço restante.

Threads e comentários

Outro caso de uso comum para o flexbox são as threads de comentários. Considere o seguinte exemplo.

Temos a foto do usuário e o próprio comentário. O comentário está ocupando o espaço restante de seu elemento pai. Esse é um uso perfeito para o flexbox.

Componentes de card

Um componente de card tem muitas variações, mas o design mais comum é semelhante ao modelo abaixo.

À esquerda, o ítens filhos do card são empilhados pois a direção definida na propriedade flex-wrapper é column. Enquanto que à direita é o oposto. A direção usada é row, e tenha em mente que row é o default para flexbox.

.card {
  display: flex;
  flex-direction: column;
}

@media (min-width: 800px) {
  .card {
    flex-direction: row;
  }
}

Outra variação comum para um cartão é ter um ícone com um label de texto abaixo dele. Pode ser um botão, link ou apenas para decoração. Considere o seguinte modelo:

Note como o ícone e o label do texto estão centralizados na horizontal e na vertical. Graças ao flexbox, isso é fácil de fazer.

.card {
  display: flex;
  flex-direction: column;
  align-items: center;
}

O estilo em linha será o padrão, basta remover a declaração flex-direction: column e deixá-la no valor padrão (row).

Tabs e Menus de botão

Quando se trata de elementos que ocupam toda a largura da tela e têm itens que devem preencher todo o espaço disponível, o flexbox é a ferramenta perfeita aqui.

No exemplo acima, cada item deve preencher o espaço disponível e deve ter largura igual. Ao configurar a exibição do wrapper para flex, isso pode ser feito facilmente.

.tabs__item {
  flex-grow: 1;
}

Essa técnica é usada no React Native para criar a barra de guias para aplicativos mobile. Aqui está um exemplo de código que faz o mesmo que o descrito acima em React Native. O código é emprestado deste local.

import React from 'react';
import { View } from 'react-native';

export default FlexDirectionBasics = () => {
    return (
      <View style=>
        <View style= />
        <View style= />
        <View style= />
      </View>
    );
};

Lista de características

O que eu mais gosto no flexbox é a capacidade de reverter a direção dos elementos. A direção padrão no flexbox é row, mas podemos revertê-la como abaixo.

.item {
  flex-direction: row-reverse;
}

Na modelo abaixo, observe como o item par é revertido, isso é feito com a técnica acima. É muito útil.

Centralizando uma seção de conteúdo

Vamos considerar que temos uma seção hero, e o conteúdo precisa estar centralizado horizontalmente e verticalmente. A centralização horizontal pode ser fácil pois poderia ser feito com o alinhamento de texto.

.hero {
  text-align: center;
}

Mas como podemos usar o flexbox para centralizar os elementos verticalmente? Aqui está o que precisamos.

.hero {
  display: flex;
  flex-direction: column;
  align-items: center; /* centralizar os elementos horizontalmente */
  justify-content: center; /* centralizar os elementos verticalmente */
  text-align: center;
}

Combinando CSS grid e Flexbox

Não apenas cada módulo de layout possui seu caso de uso, mas podemos usar ambos. Quando penso sobre combinar eles, o primeiro uso que eu vejo é uma lista de cards. Grid é usado para dispor os cards, e flexbox é usado para o componente card em si.

Aqui estão os requisitos para o layout:

A altura dos cards para cada linha deve ser igual
O link "Read more" deve ser posicionado no final do card, independentemente da sua altura.
O grid deve usar a função minmax()

<div class="wrapper">
  <article class="card">
    <img src="sunrise.jpg" alt="">
  <div class="card__content">
    <h2><!-- Title --></h2>
    <p><!-- Desc --></p>
    <p class="card_link"><a href="#">Read more</a></p>
  </div>
  </article>
</div>

@media (min-width: 500px) {
  .wrapper {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
    grid-gap: 16px;
  }
}

.card {
  display: flex; /* [1] */
  flex-direction: column; /* [2] */
}

.card__content {
  flex-grow: 1; /* [3] */
  display: flex; /* [4] */
  flex-direction: column;
}

.card__link {
  margin-top: auto; /* [5] */
}

Deixe-me explicar o CSS acima:

Faz o card um wrapper flexbox.
A direção usado é column, o que significa que os elementos cards estão empilhados
Deixa o conteúdo do card expandido e preencher o espaço restante.
Faz o conteúdo do card um wrapper flexbox.
Finalmente, usando margin-top:auto para empurrar o item para baixo. Isto irá mantê-lo posicionado ao final do card independente da altura.

Como você viu, combinar CSS grid e flexbox não é difícil. Essas duas ferramentas podem nos dar várias maneiras de implementar layouts na web. Vamos usá-los corretamente e combiná-los somente quando necessário, como acima.

Fallback e suporte a navegadores antigos

Usando CSS @supports

Há alguns meses, recebi um tweet dizendo que meu site estava quebrado no IE11. Depois de verificar, notei um comportamento muito estranho. Todo o conteúdo do site estava recolhido na área superior esquerda. Meu site não estava navegável!

Sim, este é o meu site - um site de um desenvolvedor front-end, no IE11. No começo, fiquei confuso, por que isso está acontecendo? Lembrei que o CSS grid é suportado no IE11, mas essa é a versão antiga lançada pela Microsoft. A solução é muito simples, que é usar o @supports para usar somente a grade CSS em novos navegadores.

@supports (grid-area: auto) {
  body {
    display: grid;
  }
}

Deixe-me explicar isso. Eu usava grid-area porque ela era suportada apenas na nova especificação do CSS grid, de março de 2017 até hoje. Uma vez que o IE não suporta a query @supports, toda a regra será ignorada. Como resultado, o novo CSS grid será usado apenas em navegadores que o suportam.

Usando o flexbox para suporte ao CSS grid

Se o flexbox não é adequado para exibir uma grade de itens, isso não significa que não seja bom como fallback. Você pode usar o flexbox como substituto do CSS grid para navegadores não compatíveis. Eu trabalhei em uma ferramenta que faz exatamente isso.

@mixin grid() {
  display: flex;
  flex-wrap: wrap;

  @supports (grid-area: auto) {
    display: grid;
    grid-gap: 16px 16px;
  }
}

@mixin gridAuto() {
  margin-left: -16px;

  > * {
    margin-bottom: 16px;
    margin-left: 16px;
  }

  @media (min-width: 320px) {
    > * {
      width: calc((99% / #{2}) - 16px);
      flex: 0 0 calc((99% / #{2}) - 16px);
    }
  }

  @media (min-width: 768px) {
    > * {
      width: calc((99% / #{3}) - 16px);
      flex: 0 0 calc((99% / #{3}) - 16px);
    }
  }

  @supports (grid-area: auto) {
    grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
    margin-left: 0;

    > * {
      width: auto;
      margin-left: 0;
      margin-bottom: 0;
    }
  }
}

O código de fallback acima funciona da seguinte maneira:

Adiciona display: flex e flex-wrap: wrap ao elemento wrapper.
Verifica se CSS grid é suportado, se sim, então display: grid será usado.
Usando o seletor > *, podemos selecionar os elementos filhos diretos do wrapper. Ao selecioná-los, podemos adicionar uma largura ou tamanho específico a cada um.
Obviamente, a margem entre cada uma é necessária e será substituída por grid-gap, caso CSS grid seja suportado.

Aqui está um exemplo de como usar este mixin do Sass.

.wrapper {
  @include grid();
  @include gridAuto();
}

Demostracão

Quando as coisas dão errado para o Grid e o Flexbox

Enquanto fazia uma revisão de código para o meu irmão, notei alguns usos incorretos para o CSS grid ou o flexbox e achei que seria útil se eu destacasse alguns deles.

Usar CSS grid para um cabeçalho de site

Uma das motivações deste artigo foi esse erro. Notei que meu irmão está usando CSS Grid para implementar um cabeçalho de site.

Ele mencionou coisas como "era complexo, CSS Grid é difícil... etc". Como resultado do uso de um método de layout incorreto, ele teve uma ideia de que o CSS grid é complexo. Não é, e toda a sua confusão veio do fato de usá-lo para algo que não é adequado.

Considere o seguinte exemplo que eu notei.

.site-header {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr 1fr 1fr 1fr;
}

.site-nav {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr 1fr;
}

O CSS grid foi usada duas vezes, a primeira vez foi para todo o cabeçalho e a segunda para a navegação. Ele usou grid-column para ajustar o espaçamento entre os elementos e outras coisas estranhas que não me lembro, mas você entendeu!

Usando CSS Grid para tabs

Outro uso incorreto do CSS Grid é aplicá-lo em um componente de tabs. Considere o seguinte modelo.

O código CSS incorreto se parece com o seguinte:

.tabs-wrapper {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
}

Pelo código acima, posso ver que o desenvolvedor assumiu que a contagem de tabs é de apenas três. Como resultado, ele usou 1fr 1fr 1fr para organizar as colunas. Isso pode ser quebrado facilmente se a contagem de colunas for alterada.

Uso excessivo de Flexbox ou Grid

Lembre-se de que o antigo método de layout pode ser perfeito para o trabalho. O uso excessivo de flexbox ou grid pode aumentar a complexidade do seu CSS com o tempo. Não estou dizendo que eles são complexos, mas usá-los corretamente e no contexto certo, conforme explicado nos exemplos deste artigo, é muito melhor.

Por exemplo, você tem a seguinte seção hero com uma solicitação para centralizar horizontalmente todo o conteúdo dela.

Isso pode ser feito simplesmente usando text-align: center. Porque usar flexbox quando há uma solução mais fácil?

Conclusão

Ufa, isso foi muito sobre as diferenças entre o uso de grid CSS e flexbox. Este tópico estava em minha mente por muito tempo, e eu fico feliz que eu tive a chance de escrever sobre ele. Por favor, não hesite de dar um feedback tanto por email ou twitter @shadeed9!

Obrigado pela leitura.

E é isso, espero que tenha gostado. Não deixe de seguir Ahmad Shadeed no Twitter. Ele sempre vem com textos bem completos sobre CSS e Design. E se você gostou deste post, não esqueça de curtir ele e compartilhá-lo em suas redes sociais.

Até o próximo post!

Headless CMS, o que são? onde vivem? o que comem?

Emanuel Gonçalves — Fri, 05 Jun 2020 02:48:21 +0000

Em Outubro de 2019 eu entrei para uma empresa de um produto bem interessante e de um mercado que não conhecia muito: a Storyblok. Além de trabalhar com linguagens que eu já gostava muito e com um time fera e internacional, estou tendo a oportunidade de lidar com uma tecnologia bem interessante e moderna: Headless CMS.

O motivo para a escrita deste texto é trazer para você conhecimentos que eu não tive no passado e despertar o interesse por novas soluções no ecossistema de CMS. Então, esquece de colocar no Google Tradutor o termo "Headless CMS", porquê a resposta não é animadora (spoiler: é "CMS Sem cabeça"). Venha conferir o que são Headless CMS, onde vivem, e o que comem.

Evolução do conceito de CMS na internet

Antes, vamos investigar rapidamente a evolução que a internet teve e o papel dos Gerenciadores de Conteúdo nessa evolução.

A Web 1.0

Características:

Estática, os navegadores apenas entendiam HTML e a interação era nula;
Celeiro de informações: a Web 1.0, mesmo tendo as características acima, era extremamente revolucionária, pois agora era possível armazenar conhecimento e compartilhá-lo como jamais visto.
Armazenamento em arquivos: a web era feita de arquivos HTML que eram publicados através de um FTP. Precisa mudar o conteúdo? Edite o arquivo e suba novamente.

Com o advento dos anos 2000 e o surgimento de ferramentas como PHP e ASP, a Web passou por uma grande mudança, vindo agora a Web 2.0.

A Web 2.0

Sem dúvida, o que propiciou o surgimento dessa revolução foram ao menos três fatores:

Possibilidade de criação de conteúdo dinâmico. Era possível deixar comentários nos posts, por exemplo.
O conteúdo poderia ser armazenado em bases de dados, diferentemente do formato anterior, em que o conteúdo era armazenado em arquivos, como por exemplo, o próprio HTML.
Surgimento de linguagens que permitiam uma dinamização na criação de conteúdo e acesso à base de dados, como PHP e ASP.

Portanto, a principal característica da Web era ser dinâmica, sendo assim possível adicionar conteúdos, editá-los e o consumidor final (o usuário) poder interagir com este conteúdo, por exemplo, criando comentários em posts.

É aqui que os grandes players do mercado de CMS surgem (mais a frente iremos investigar o que são os CMSs) como o Wordpress e o Drupal e os Site Builders, que são ferramentas que praticamente constroem o site para você. Tudo isso surge para facilitar a vida dos produtores de conteúdo, pois agora não era mais necessário ter conhecimentos específicos de programação web para ter um site no ar.

Porém, mais um elemento é adicionado a sociedade: o smartphone. E com ele, a possibilidade de acessar as mesmas páginas web que antes o usuário acessava no computador por esse novo dispositivo.

A Web 3.0

Com o advento dos smartphones e algumas evoluções no acesso aos dados, como por exemplo, a possibilidade de automação da leitura de uma página web (criação dos crawlers web), a web precisou se reinventar. Surgindo assim a Web semântica. É nesta era que surge o HTML5, que possibilita a estruturação do conteúdo web para que não humanos entendam.

Tal evolução trouxe um grande desafio aos CMSs: praticamente qualquer dispositivo consegue acessar a internet. Temos não apenas computadores, smartphones e tablets que acessam a internet, mas geladeiras, arduínos, smartwatches entre outros. Na presente era da internet, que alguns comumente chamam de Web 4.0, o desafio é entregar o conteúdo para qualquer dispositivo da melhor maneira.

Mas, e os CMS?

Um CMS (sigla para Content Management System - Sistema de Gerenciamento de conteúdo), é um software responsável por gerenciar o conteúdo, ou seja, permitir a criação, edição e organização de um determinado conteúdo.

Ele precisa possuir, ao menos, alguns destes elementos:

Um Dashboard para o produtor de conteúdo: é aqui que temos a liberdade para gerenciar o conteúdo, criar páginas, editá-las, escolher os temas que queremos entre outros.
Ferramentas para publicação do conteúdo. Uma das etapas mais importantes é a publicação do conteúdo, ou seja, disponibilizá-lo na rede. Um CMS precisa de uma ferramenta para publicar o conteúdo e ela precisa ser simples para o usuário, já que o objetivo é que pessoas sem conhecimento técnico possam fazer uso de um CMS.

Com a possibilidade de variados dispositivos acessarem a internet, o que chamamos de Internet das Coisas, surge um desafio aos CMSs tradicionais, vejamos.

O problema dos CMSs tradicionais

Proponho a seguinte analogia para entendermos qual o principal problema de um CMS Tradicional e o surgimento dos Headless CMSs:

// Detect dark theme var iframe = document.getElementById('tweet-1264622637507997696-77'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1264622637507997696&theme=dark" }

Traduzindo...
Um CMS Tradicional é como o livro que você compra em uma livraria. Quer acessar o conteúdo? Você pega o livro e lê ele, e esta é a única forma. Um Headless CMS é como comprar um eBook. Você lê ele no Amazon Kindle, ou você usa o aplicativo do Kindle no PC, Mac, smartphone ou Tablet.

O principal problema de um CMS Tradicional é que o conteúdo está "amarrado" à implementação do CMS. Em termos técnicos, Front-End (o resultado final para quem consome o conteúdo) está acoplado ao Back-End (implementação do CMS). Como na analogia acima, o conteúdo (texto escrito pelo autor do livro) pode estar amarrado à uma interface física (livro) ou desacoplado da mesma (ebook), possibilitando seu consumo em diferentes interfaces.

Veja a seguinte imagem que mostra a mesma ideia da analogia anterior:

Fonte: https://www.contentstack.com/blog/all-about-headless/headless-cms-vs-building-custom-cms

Portanto, os Headless CMSs surgem para suprir essa necessidade de gerenciar o conteúdo da melhor forma para diferentes dispositivos. Mas como se dá isso?

Conhecendo mais a fundo um headless CMS

Já vimos um pouco da evolução da internet e como os CMSs estavam e estão nela. Vimos como funciona um CMS tradicional e como ele, no novo contexto da internet, possui algumas limitações e também vimos como os Headless CMSs as suprem. Mas, como funciona um Headless CMS?

Um Headless CMSs irá prover uma interface tal como um CMS comum teria. Porém, a diferença primordial dele é que, no final, você não terá o Front End pronto. Você precisará desenvolver um que consuma o conteúdo que está no CMS. Assim, um Headless CMS não se preocupa em como o seu conteúdo ficará no final, ele se preocupa apenas em como o conteúdo estará estruturado.

Quais as vantagens?

Como a preocupação é apenas com a estrutura do conteúdo e o Front End é desacoplado da solução, temos como consequência:

A flexibilidade para escolher a tecnologia que você deseja usar e julga ser a melhor para o projeto.
Facilidade de configuração e implantação do código, pois você não precisará de um Back End, apenas do Front. Então qualquer static hoisting irá ser suficiente.
A flexibilidade para transpor o mesmo conteúdo para ambientes/dispositivos diferentes, que outrora era a maior dificuldade que CMS tradicional enfrentava.

A melhor parte: Headless CMS não diz respeito apenas a web sites. Você pode usar um Headless CMS para a criação de aplicativos mobile e desktop, entre outros usos.

E as desvantagens?

Creio que há ao menos duas desvantagens que você pode encontrar ao usar um Headless CMS, mas que são contornáveis:

Como o seu site não está acoplado ao CMS, não será possível fazer uso de ferramentas de Analytics diretamente pela plataforma/ferramenta que gerencia o conteúdo, como por exemplo, saber quantas pessoas acessaram o site, quais páginas visitaram entre outros dados. Porém, você pode usar o seu static hosting para ter essas informações ou usar o Google Analytics em conjunto com o Google Search
Você poderá não ter acesso ao resultado final do conteúdo estruturado ao mesmo tempo que gerencia ele. Como Front e Back não estão juntos, você pode achar que criar a estrutura do conteúdo seja algo muito abstrato. Porém, existe uma solução de Headless CMS que o core feature é a solução para isso: a Storyblok 😜😏.

Quais os tipos

Podemos separar as soluções de Headless CMS em dois tipos, baseados em como ocorre a entrega e o consumo dos dados:

API driven

Esta é a solução mais comum. O CMS disponibiliza uma API para o consumo dos dados, e o Front End a usa. Alguns exemplos de soluções no mercado são: Storyblok, Contentful e Prismic

Alguns pontos positivos desta solução são:

Melhor solução para múltiplos front-ends
Mais fácil de lidar quando há muito conteúdo

Mas alguns pontos negativos são:

Geralmente vem com limite no consumo de dados
Como não é integrado ao Git, pode ser complicado reverter mudanças

Git driven

Nesta solução, cada alteração no conteúdo irá gerar um novo commit num repositório git, e assim, uma nova versão do site será gerada. Alguns exemplos são: NetlifyCMS e Forestry.

Alguns pontos positivos desta solução são:

Configuração simples
Fácil voltar uma versão, seja específica ou não
Integração com o git permite uma curva de aprendizado melhor (claro, se já souber e dominar o git)

Porém, alguns pontos negativos são:

A forma como o conteúdo irá ser estruturado é limitado
Se o site tiver bastante conteúdo, pode ser um problema
Se há vários sites/aplicativos acessando o mesmo conteúdo, pode não ser a melhor escolha

Recomendo fortemente a leitura do artigo do Bejamas (em inglês) a respeito desse assunto.

Considerações finais

Headless CMS é uma solução bem interessante para o seu próximo blog, seu website de campanha de marketing ou até mesmo sua página pessoal na web. Existem inúmeras soluções no mercado. Recomendo o post do time do Bejamas sobre essas diferentes soluções. É um excelente comparativo, mostrando prós e contras de cada solução.

Vejo você no próximo post!

Leituras adicionais

Agradecimentos ao Vinicius Reis pela revisão e pela imagem 😎

Suspense - uma nova feature no Vue3

Emanuel Gonçalves — Mon, 03 Feb 2020 19:48:23 +0000

Fala galera, esta é mais uma tradução livre de um artigo do pessoal do Vueschool, dessa vez sobre uma outra feature do Vue 3, que é o componente Suspense. Não deixe de conferir!

Link do post original escrito pelo Filip Rakowski.

Recentemente eu escrevi um artigo sobre as novas features disponíveis no Vue 3 (texto também traduzido) onde eu brevemente introduzi quais features podemos esperar na próxima major release do Vue.js.

No artigo de hoje, eu quero falar um pouco mais sobre uma das mais interessantes - Suspense.

Este artigo é baseado no repositório vue-next. Não há garantia de que os recursos mencionados neste artigo cheguem ao Vue 3 exatamente da forma descrita (mas é provável que aconteça).

O que é o Suspense?

Suspense é um componente especial que renderiza um conteúdo de fallback em vez do seu componente até que uma condição seja atendida. Essa condição geralmente é uma operação assíncrona acontecendo na função setup de seus componentes. Esta é uma técnica bem conhecida do ecossistema React.

Se isso parece estranho para você, não se assuste. Eu vou me aprofundar nisso brevemente.

Com a Composition API, Vue 3 irá introduzir um método setup, que permite conectar diferentes propriedades de componentes com funções como computed() ou onMounted(). Propriedades retornadas pelo método setup estarão disponíveis no template Vue da mesma forma que data, methods, e computeds da Options API do Vue 2 são disponíveis agora.

<template>
  <div> 
    Clicked <b>{{ count }}</b> times. 
    <button @click="increment">Increment</button>
  </div>
</template>

<script>
import { ref } from 'vue'

export default {
  setup () {
    const count = ref(0)
    function increment () {
      count.value++
    }    

    return { 
      count,
      increment
    }
}
</script>

Às vezes você quer realizar uma operação assíncrona no método setup como uma requisição de dados para uma API externa (similarmente ao se faz atualmente no método created).

export default {
  async setup () {
    const user = await fetchUser()
    return { user }    
  }
}

Neste caso, você provavelmente não quer visualizar seu componente enquanto se está buscando os dados do usuário. Você provavelmente quer visualizar algum indicador de loading enquanto se está sendo buscado os dados. É exatamente para isso que o Suspense foi feito!

Se nós encapsulamos o componente abaixo em um Suspense, ele irá mostrar uma conteúdo de fallback enquanto a operação assíncrona do seu componente é resolvida.

<Suspense>
  <template #default>
    <UserProfile />
  </template>
  <template #fallback>
    <div>Loading...</div>
  </template>
</Suspense>

Muito elegante, não? Também podemos suspender o carregamento para vários componentes assíncronos.

Se tivermos outro componente que busca imagens engraçadas de gatos e o coloca junto com o componente UserProfile, o conteúdo de fallback será mostrado até que ambos os componentes resolvam suas operações assíncronas:

<Suspense>
  <template #default>
    <UserProfile />
    <FunnyCats /> 
  </template>
  <template #fallback>
    <div>Loading...</div>
  </template>
</Suspense>

Manipulação de erros

Até agora, cobrimos o que acontece quando as operações assíncronas são resolvidas com êxito, mas o que acontece se elas falharem e forem rejeitadas?

Felizmente, podemos usar o novo hook de ciclo de vida ErrorCaptured para capturar erros como esse e exibir uma mensagem de erro adequada. Veja o exemplo abaixo:

<template>
  <div v-if="error">
   {{ error }}
  </div>
  <Suspense v-else>
    <template #default>
      <UserProfile />
    </template>
    <template #fallback>
      <div>Loading...</div>
    </template>
  </Suspense>
</template>

<script>
import { onErrorCaptured } from 'vue'

setup () {
  const error = ref(null)
  onErrorCaptured(e => {
    error.value = e
    return true
  })}
  return { error }
</script>

No exemplo acima, nós visualizamos um conteúdo de fallback até que a operação assíncrona em UserProfile seja resolvida. Se algo acontece de errado e ela é rejeitada, nós usamos o hook onErrorCaptured do Vue para capturar o erro e passá-lo para uma propriedade error e visualizá-la ao invés do nosso conteúdo de fallback.

Resumo

Suspense é um componente muito acessível que disponibiliza uma maneira fácil e elegante de visualizar um conteúdo de fallback enquanto operações assíncronas são executadas. Com o hook de ciclo de vida ErrorCaptured você também pode graciosamente manipular os erros que acontecem no seu componente "suspendido".

Bom, mais uma tradução finalizada. Espero que tenha gostado. Não deixe de compartilhar este post para que mais pessoas sejam alcançadas por este conhecimento.

Até a próxima!

Portal - uma nova feature no Vue 3

Emanuel Gonçalves — Fri, 24 Jan 2020 11:18:05 +0000

Fala galera, esta é mais uma tradução livre de um artigo do pessoal do Vueschool, dessa vez sobre uma outra feature do Vue 3, que são os Portals ou Portais. Não deixe de conferir!

Link do post original escrito pelo Filip Rakowski.

Recentemente eu escrevi um artigo sobre as novas features disponíveis no Vue 3 (texto também traduzido) onde eu brevemente introduzi quais features podemos esperar na próxima major release do Vue.js.

No artigo de hoje, eu quero falar um pouco mais sobre uma das mais úteis - Portais.

Este artigo é baseado no repositório vue-next. Não há garantia de que os recursos mencionados neste artigo cheguem ao Vue 3 exatamente da forma descrita (mas é provável que aconteça).

O que é um portal?

Portal é um conceito bem conhecido do React que também foi adotado no Vue 2 através de plugins de terceiros como o portal-vue. Como o nome sugere, ele é responsável por "teletransportar" algo de um lugar para outro... E é exatamente o que ele faz!

Com um portal, você pode renderizar um componente em um local diferente na árvore DOM, mesmo que este local não esteja no escopo do seu app. Portais são muito convenientes quando trabalhamos com modals, notifications, popups e outros elementos que são sensíveis ao local em que eles estão na árvore DOM.

Deixe-me te mostrar:

<!-- UserCard.vue -->
<template>
  <div class="user-card">
    <b> {{ user.name }} </b>  
    <button @click="isPopUpOpen = true">Remove user</button>
    <div v-show="isPopUpOpen">
      <p>Are you sure?</p>
      <button @click="removeUser">Yes</button>
      <button @click="isPopUpOpen = false">No</button>
    </div>
  </div>
</template>

No código acima nos temos um componente UserCard que nos permite remover um determinado usuário de um banco de dados. Depois de clicar no botão, nós iremos ver um popup de confirmação no qual podemos confirmar a ação e remover o usuário usando o método removeUser.

Manter componentes relacionados (o popup de confirmação por exemplo) no mesmo local é uma boa prática em termos de manutenção de código. Mas, quando se trata de elementos de UI que podem aparecer acima de outros, podemos ter alguns problemas.

O primeiro problema que podemos encontrar é o fato de que a classe user-card, assim como qualquer outra classe mais alta na hierarquia do DOM, pode afetar a aparência do nosso popup. Por exemplo, se qualquer container definir visibility: 0.5, a visibilidade de nosso popup também será afetada.

Garantir que nosso popup irá aparecer no topo de outros elementos é um outro desafio. Você pode pensar no elementos DOM como camadas. Nós colocamos estas camadas acima de outras para construir um layout. Normalmente, quando nós queremos cobrir uma dessas camadas com outras, nós fazemos isso intencionalmente colocando outros elementos dentro dessa camadas ou depois dela.

Uma das formas de resolver este problema é usando a propriedade z-index do CSS para mudar a ordem natural de aparência de um elemento. Contudo, este método não é muito elegante e normalmente nos traz outros desafios para enfrentar, como quando temos outros elementos posicionados com z-index.

É por isso que geralmente colocamos elementos de UI que devem aparecer em cima dos outros antes da tag de fechamento </body>. Dessa forma, não precisamos fazer hacks para garantir que nosso popup seja exibido exatamente onde e como queremos. Também garante que outros elementos não o cubram.

Portanto, parece que temos duas boas práticas que entram em conflito:

O primeiro diz para mantermos os componentes relacionados juntos, o que implica manter o componente popup dentro do componente UserCard.
O segundo nos diz para colocar o componente popup imediatamente antes do fechamento da tag body.

Para atender a ambos os requisitos, precisamos garantir que, mesmo que o código do nosso popup esteja localizado no componente UserCard, ele seja renderizado em outro lugar - idealmente antes do fechamento da tag body.

Felizmente, é exatamente para isso que os portais foram criados!

Portais no Vue 3

Entre muitos outros recursos, o Vue 3 virá com suporte nativo para portais na através do componente Portal.

A boa notícia é que o componente Portal é muito simples! Ele possui apenas uma propriedade, target, e um slot padrão. O conteúdo do slot será renderizado no elemento DOM, selecionado pelo seletor de consulta passado na propriedade target do componente Portal.

<!-- In some nested Vue component -->
<NestedComponent>
  <Portal target="#popup-target">
    <PopUp />
  </Portal>
</NestedComponent>
<!-- before closing body tag -->
<div id="popup-target"></div>

No exemplo acima, o componente PopUp irá ser renderizado numa div com um id popup-target, mesmo que esteja posicionado dentro de um componente NestedComponent.

Sabendo disso, podemos reescrever nosso componente UserCard neste formato:

<!-- UserCard.vue -->
<template>
  <div class="user-card">
    <b> {{ user.name }} </b>  
    <button @click="isPopUpOpen = true">Remove user</button>
    <Portal target="#popup-target">
      <div v-show="isPopUpOpen">
        <p>Are you sure?</p>
        <button @click="removeUser">Yes</button>
        <button @click="isPopUpOpen = false">No</button>
      </div>
    </Portal>
  </div>
</template>

Simples e fácil, não é? Agora, podemos manter nosso código estruturado corretamente, sem ser forçados a executar soluções desagradáveis para mantê-lo funcionando!

Se você ainda está curioso e deseja ver outros exemplos, aqui você pode encontrar um pequeno site com uma modal, usando os portais do Vue 3. Você também pode procurar por cenários de teste no repositório vue-next.

Resumo

Portal é uma das adições mais interessantes do Vue 3. Simplifica o trabalho com elementos como modais e popups e torna extremamente fácil renderizá-los sobre outros elementos do DOM sem soluções feias.

Bom, mais uma tradução finalizada. Espero que tenha gostado. Não deixe de compartilhar este post para que mais pessoas sejam alcançadas por este conhecimento. Definitivamente, portais serão muito úteis em nosso dia-a-dia desenvolvendo com Vue.js.

Até a próxima!

Conheça as novas funcionalidades do Vue 3

Emanuel Gonçalves — Mon, 20 Jan 2020 15:32:55 +0000

Este texto é uma livre tradução do artigo do time do Vueschool sobre as novas funcionalidades que irão vir no Vue 3. Então, desde já agradecemos ao excelente artigo escrito por Filip Rakowski que você pode conferir aqui. Vamos ao texto?

No antigo anterior, nós aprendemos sobre as melhorias de performance que Vue 3 irá trazer. Nós já sabemos que apps escritos na nova versão do Vue irão performar melhor mas esta não é a melhor parte. O que mais importa para nós desenvolvedores é como esta nova release irá afetar a forma como nós desenvolvemos.

Como você poderia esperar, Vue 3 traz uma série de novas e emocionantes características. Felizmente, a equipe do Vue introduziu, em vez de grandes mudanças, adições e melhorias nas APIs atuais, para que as pessoas que já conhecem o Vue 2 se sintam à vontade rapidamente com as novas sintaxes.

Vamos começar com a API, você provavelmente já ouviu falar a respeito...

Composition API

Composition API é a syntax feature mais discutida desta nova versão do Vue. É uma abordagem completamente nova para reuso de lógica e organização de código.

Normalmente nós construímos nossos componentes com o que nós chamamos de Options API. Para adicionar lógica aos componentes Vue nós preenchemos propriedades tais como data, methods, computed etc. A maior desvantagem dessa abordagem é o fato de que esse não é como um código JavaScript em si. Você necessita saber exatamente quais propriedades estão acessíveis no templates assim como o comportamento do this. Por baixo do capô, o compilador Vue precisa transformar estas propriedades em um código funcional. Por causa disso, nós não temos os benefícios de coisas como auto sugestões (autocomplete de editores) ou checagem de tipo (type checking).

A Composition API visa solucionar este problema, expondo os mecanismos atualmente disponíveis nas propriedades do componente como funções JavaScript. O Core Team do Vue descreve a Composition API como "um conjunto de APIs baseadas em funções que permitem composições flexíveis de lógica de componentes". Código escrito usando a Composition API é mais legível e não há mágica por trás, o que faz com seja mais fácil de ler e aprender.

Vamos ver um exemplo simples de um componente que usa a nova Composition API para entender como ela funciona:

<template>
  <button @click="increment">
    Count is: {{ count }}, double is {{ double }}, click to increment.
  </button>
</template>

<script>
import { ref, computed, onMounted } from 'vue'

export default {
  setup() {
    const count = ref(0)
    const double = computed(() => count.value * 2)

    function increment() {
      count.value++
    }

    onMounted(() => console.log('component mounted!'))

    return {
      count,
      double,
      increment
    }
  }
}
</script>

Agora, vamos quebrar este código em algumas partes para entender o que está acontecendo:

import { ref, computed, onMounted } from 'vue'

Como mencionado antes, a Composition API expõe propriedades de componentes como funções, então a primeira etapa é importar as funções de que nós precisamos. Em nosso caso, precisamos criar uma referencia reativa com a função ref, uma propriedade computada com computed e acessar o hook de ciclo de vida com onMounted.

Agora, você provavelmente está se perguntando: o que é este misterioso método setup?

export default {
  setup() {
  }
}

Em poucas palavras é apenas uma função que retorna propriedades e funções para o template. É só isso. Nós declaramos todas as propriedades reativas, propriedades computadas, watchers, hooks de ciclo de vida aqui e então retornamos eles para que possam ser usadas no template.

O que não retornamos na função setup não estará disponível no template.

const count = ref(0)

No código acima nós declaramos uma propriedade reativa chamada count usando a função ref. Ela pode encapsular qualquer valor primitivo ou objeto e retorná-lo como uma propriedade. O valor passado será mantido na propriedade value da referência criada. Por exemplo, se você quiser acessar o valor de count, você precisa explicitamente chamar por count.value.

const double = computed(() => count.value * 2)

function increment() {
  count.value++
}

... e isso é exatamente o que nós fazemos quando declaramos a propriedade computada double e a função increment.

onMounted(() => console.log('component mounted!'))

Com o hook onMounted nós estamos exibindo alguma mensagem quando o componente é montado só para mostrar para você que você pode 😉.

return {
  count,
  double,
  increment
}

No final estamos retornando as propriedades count e double com o método increment para que eles estejam disponíveis no template.

<template>
  <button @click="increment">
    Count is: {{ count }}, double is {{ double }}. Click to increment.
  </button>
</template>

E voila! Agora nós podemos acessar as propriedades e funções retornadas pelo método setup no template da mesma forma que eles estavam declarados quando da antiga Options API.

Este é um simples exemplo, que poderia ser facilmente realizado com a Options API. O verdadeiro benefício da nova Composition API não é apenas desenvolver de uma forma diferente, os benefícios se revelam quando se trata de reutilizar nosso código/lógica.

Reuso de código com a Composition API

Há mais vantagens na nova Composition API. Vamos falar sobre reuso de código. Normalmente, se nós queremos compartilhar algum código entre componentes há duas opções disponíveis - mixins e scoped slots. Ambos tem suas desvantagens.

Vamos dizer que nós queremos extrair uma funcionalidade chamada counter e reaproveitá-la em outro componente. Abaixo, você pode ver como poderíamos fazer isso usando as APIs disponíveis e a nova Composition API:

Vamos começar com mixins:

import CounterMixin from './mixins/counter'

export default {
  mixins: [CounterMixin]
}

A principal desvantagem dos mixins é o fato de nós não sabermos nada sobre o que eles estão adicionando ao nosso componente. Isso torna não apenas difícil de entender o código, mas também pode levar a colisões de nomes com propriedades e funções existentes.

Agora os scoped slots.

<template>
  <Counter v-slot="{ count, increment }">
     {{ count }}
    <button @click="increment">Increment</button> 
  </Counter> 
</template>

Com scoped slots nós sabemos exatamente quais propriedades nós podemos acessar através da propriedade v-slot então fica muito mais fácil entender o código. A desvantagem dessa abordagem é que podemos acessá-la apenas em um template e estar disponível apenas no escopo do componente Counter.

Agora, vamos ver como fica com a Composition API:

function useCounter() {
  const count = ref(0)
  function increment () { count.value++ }

  return {
    count,
    incrememt
  }
}

export default {
  setup () {
    const { count, increment } = useCounter()
    return {
      count,
      increment
    }
  }
}

Muito mais elegante não é? Nós não estamos limitados nem pelo template nem pelo escopo dos nossos componentes e sabemos exatamente quais propriedades de counter nós podemos acessar. Adicionado a isso, temos o benefício de termos auto complete do nosso código disponível em nosso editor pois useCounter é apenas uma função que retorna algumas propriedades. Não há mágica por trás, então o editor pode nos ajudar com checagem de tipo e sugestões.

Também é uma forma mais elegante de usarmos biblioteca de terceiros. Por exemplo, se nós queremos usar o Vuex nós explicitamente usamos a função useStore ao invés de poluir o protótipo do objeto Vue (this.$store). Essa abordagem também apaga a mágica dos que acontece nos bastidores dos plug-ins Vue.

const { commit, dispatch } = useStore()

Se você quiser aprender um pouco mais sobre Composition API e seus casos de uso, eu recomendo fortemente ler este documento escrito pelo time do Vue que explica o raciocínio por trás da nova API e sugere os melhores casos de uso dela. Há também este excelente repositório com exemplos de uso da Composition API mantido por Thorsten Lünborg, um membro do core team do Vue.

Mudanças na API de montagem/configuração global

Nós encontramos outra mudança grande na forma que nós instanciamos e configuramos nossa aplicação. Vamos ver como isso irá ficar:

import Vue from 'vue'
import App from './App.vue'

Vue.config.ignoredElements = [/^app-/]
Vue.use(/* ... */)
Vue.mixin(/* ... */)
Vue.component(/* ... */)
Vue.directive(/* ... */)

new Vue({
  render: h => h(App)
}).$mount('#app')

Atualmente nós usamos o objeto global do Vue para nos prover qualquer configuração e criar novas instâncias do objeto Vue. Qualquer mudança feita num objeto Vue irá afetar todas as outras instâncias e componentes.

Agora, vamos ver como isso irá funcionar no Vue 3:

import { createApp } from 'vue'
import App from './App.vue'

const app = createApp(App)

app.config.ignoredElements = [/^app-/]
app.use(/* ... */)
app.mixin(/* ... */)
app.component(/* ... */)
app.directive(/* ... */)

app.mount('#app')

Como você provavelmente percebeu agora, todas as configurações têm o escopo definido para uma determinada aplicação Vue definida com a função createApp.

Atualmente, se alguma solução de terceiros estiver modificando o objeto Vue, ela poderá afetar sua aplicação de maneiras inesperadas (especialmente com mixins globais), o que não será possível com o Vue 3.

Esta mudança de API está sendo discutida atualmente neste RFC, o que significa que potencialmente poderá mudar no futuro.

Fragments

Outra emocionante adição que nós podemos esperar no Vue 3 são os fragmentos.

O que são fragmentos? Bem, se você criar componentes Vue, eles só podem ter apenas um nó central.

Isso significa que um componente como este não poderá ser criado:

<template>
  <div>Hello</div>
  <div>World</div>
</template>

A razão para isso é que a instância do Vue que representa qualquer componente Vue precisa ser vinculado a um único elemento DOM. A única forma que você tem para criar um componente com múltiplos nós DOM é criando um componente funcional que não tem fundamento na instância do Vue.

Acontece que a comunidade React teve o mesmo problema. A solução que eles trouxeram foi criar um elemento virtual chamado Fragment. Parece mais ou menos assim:

class Columns extends React.Component {
  render() {
    return (
      <React.Fragment>
        <td>Hello</td>
        <td>World</td>
      </React.Fragment>
    );
  }
}

Apesar de Fragments se parecerem com um elemento DOM normal eles são virtuais e não serão renderizados na árvore DOM. Dessa forma, podemos vincular a funcionalidade do componente em um único elemento sem criar um nó DOM redundante.

Atualmente nós podemos usar Fragments no Vue 3 com a biblioteca vue-fragments e no Vue 3 você os terá pronto para usar!

Suspense

Outra grande ideia do ecossistema React que será adotado pelo Vue é o componente Suspense.

Suspense suspenderá a renderização de seu componente e renderizará um componente fallback* até que uma condição seja atingida. Durante a Vue London, Evan You tocou brevemente neste tópico e nos mostrou a API que mais ou menos podemos esperar. Acontece que o Suspense será apenas um componente com slots:

<Suspense>
  <template >
    <Suspended-component />
  </template>
  <template #fallback>
    Loading...
  </template>
</Suspense>

Um conteúdo de fallback* será exibido até que o componente Suspended-component seja inteiramente renderizado. Suspense pode esperar até o download do componente, se for um componente assíncrono, ou executar algumas ações assíncronas na função setup.

Múltiplos v-models

v-model é uma diretiva que nós usamos para realizar um two-way data binding em um dado componente. Nós podemos passar uma propriedade reativa e modificá-la de dentro de um componente.

Conhecemos bem o v-model pelo seu uso em componentes de formulário.

<input v-model="property />

Mas você sabia que pode usar o v-model com cada componente? Por baixo do capô ele é apenas um atalho para um mecanismo de passar uma propriedade value e ouvir um evento input. Reescrevendo o exemplo acima para a sintaxe abaixo teremos o mesmo efeito:

<input 
  v-bind:value="property"
  v-on:input="property = $event.target.value"
/>

Nós ainda podemos alterar o nome padrão das propriedades e os nomes dos eventos com a propriedade model do componente.

model: {
  prop: 'checked',
  event: 'change'
}

Como você pode ver a diretiva v-model pode nos dar um açucar sintático muito útil quando queremos ter um two-way data binding em nossos componentes. Infelizmente você só pode ter apenas um v-model por componente.

Felizmente, isso não será um problema no Vue 3! Você poderá dar nomes às propriedades do v-model e ter quantas delas desejar. Abaixo você encontra um exemplo de dois v-models em um componente de formulário:

<InviteeForm
  v-model:name="inviteeName"
  v-model:email="inviteeEmail"
/>

Esta mudança na API está atualmente sendo discutida neste RFC o que significa que potencialmente poderá mudar no futuro.

Portals

Portais são componentes especiais determinados a renderizar certo conteúdo fora do componente atual. É também uma feature nativamente implementada no React. Isso é o que a documentação oficial do React diz sobre os portais:

"Os portais fornecem uma maneira first-class de renderizar filhos em um nó DOM que existe fora da hierarquia DOM do componente pai."

É uma maneira muito interessante de lidar com modais, popups e outros componentes que geralmente aparecem no topo da página. Ao usar portais, você pode ter certeza de que nenhuma das regras CSS do componente pai afetará o componente que você deseja exibir e o isentará de executar hacks desagradáveis com o z-index.

Para cada portal precisamos especificar qual o destino alvo onde o conteúdo do portal será renderizado. Abaixo você pode ver uma implementação da biblioteca portal-vue que adiciona essa funcionalidade ao Vue 2.

<portal to="destination">
  <p>This slot content will be rendered wherever thportal-target with name 'destination'
    is  located.</p>
</portal>

<portal-target name="destination">
  <!--
  This component can be located anywhere in your App.
  The slot content of the above portal component wilbe rendered here.
  -->
</portal-target>

O Vue 3 terá suporte nativo aos portais!

Nova API para diretivas customizadas

Diretivas customizadas irão mudar superficialmente no Vue 3 para melhor se alinhar com o ciclo de vida dos componentes. Esta mudança poderá tornar a API mais fácil de se entender e aprender para iniciantes, pois será mais intuitiva.

Esta é a API atual:

const MyDirective = {
  bind(el, binding, vnode, prevVnode) {},
  inserted() {},
  update() {},
  componentUpdated() {},
  unbind() {}
}

... e isto é como ela irá se parecer no Vue 3:

const MyDirective = {
  beforeMount(el, binding, vnode, prevVnode) {},
  mounted() {},
  beforeUpdate() {},
  updated() {},
  beforeUnmount() {}, // new
  unmounted() {}
}

Mesmo sendo uma breaking change, ela deve ser facilmente coberta com uma ferramenta de compatibilidade do Vue.

Esta mudança na API está atualmente sendo discutida neste RFC o que significa que potencialmente poderá mudar no futuro.

Psst! Você pode aprender como dominar diretivas customizas em nosso curso.

Sumário

Além da Composition API, que é a maior e mais nova API do Vue 3, também podemos encontrar muitas melhorias menores. Podemos ver que o Vue está caminhando para uma melhor experiência de desenvolvimento e uma API mais simples e intuitiva. Também é bom ver que a equipe do Vue decidiu adotar muitas idéias que estão disponíveis atualmente apenas através de bibliotecas de terceiros para o núcleo do framework.

A lista acima contém apenas as principais alterações e melhorias da API. Se você estiver curioso sobre outras, verifique o repositório de RFCs do Vue.

Bom, está é a tradução. Espero que tenha gostado. Não deixe de compartilhar este post para que mais pessoas o encontrem e se surpreendam com as mudanças bastante positivas que o time do Vue está trazendo.

Até a próxima!

Re-Lançamento do Acessibilidade for Devs

Emanuel Gonçalves — Mon, 21 Oct 2019 20:52:42 +0000

Fala! Tudo bem? Gostaria de compartilhar algo rapidamente com você.

Você se interessa pelo assunto da acessibilidade? Você gostaria de deixar seus sites mais acessíveis, mas não sabe por onde começa? Você acha confuso aprender todas aquelas recomendações da W3C? Então te apresento um projeto um pouco velho (existe desde 2016) que pode te ajudar nisso. É o Acessibilidade for Devs.

O que é o projeto?

O Acessibilidade for Devs surgiu em 2016 como um guia de estudos escrito por mim para me orientar no desenvolvimento de aplicações web acessíveis. Na época eu criei uma organização no Github com dois repositórios:

O guia em si.
Um fórum no estilo do Front End BR com as perguntas sendo as ISSUES do Github.

Infelizmente, por uma falha minha, acabei não dando atenção no projeto na época, e assim ele ficou largado :(

Porém, esta realidade está mudando. Recentemente eu reescrevi o site usando o Vuepress para facilitar a escrita do conteúdo (basta escrever em arquivos .md), criei algumas ISSUES com algumas melhorias pertinentes e estou precisando de você para dar uma ajuda neste trabalho.

O DNA do projeto

Este projeto não visa competir com nenhum outro projeto para ajudar desenvolvedores a entender e desenvolver a acessibilidade em seus sites. Pelo contrário, ele é da comunidade para a comunidade. O projeto vem para somar a esse movimento que já amadureceu muito desde 2016 quando eu comecei a me atentar a questão da acessibilidade.

No que eu posso ajudar?

Há algumas formas de você ajudar este projeto:

Você encontrou algum problema no conteúdo? Um erro gramatical, por exemplo. Submeta seu PR com a correção.
Você manja bastante de inglês? Pode ajudar com a tradução do conteúdo de português para inglês.
Encontrou algum conteúdo novo sobre acessibilidade, algum tutorial bem bacana sobre o assunto? Contribua colocando ele no Guia, submetendo seu PR
Existe algumas ISSUES no repositório. Se tiver condições de pegar uma para resolver também ajuda :)
Por fim, mas não menos importante, se tiver alguma opinião em como o conteúdo pode ser organizado, pode submeter seu PR com a melhoria ou criar uma ISSUE com sua opinião. Sua crítica será muito bem vinda

Eu não sou um expert no assunto. Sou um curioso que pretende usar de sua curiosidade para aprender e facilitar o aprendizado de outras pessoas a respeito de um assunto tão importante em nossos dias.

Espero que este texto possa ter despertado sua curiosidade para o projeto e não deixe de compartilhar, não apenas o texto, mas a organização no Github. Muito obrigado!

Sou Emanuel, Engenheiro Front End e entusiasta de Inteligência Artificial. Maluco por séries e filmes. Amo programação e tudo que a cerca. Conheça meu trabalho no meu site emanuelgsouza.dev e em meu Github. May the force be with you!

Aprendendo Ruby como um Dev JavaScript parte 1

Emanuel Gonçalves — Fri, 13 Sep 2019 18:33:07 +0000

Fala Codecaster!! Trazemos para você mais um texto aqui na Publicação do Codecasts. Hoje o tema é Ruby. A motivação de trazer este conteúdo é devido ao fato de que recentemente eu tenho buscado estudar um pouco essa linguagem, mais a título de conhecimento. Sendo assim, como um Desenvolvedor Web que lida a mais de 2 anos com JavaScript, preferi traçar paralelos com a linguagem que mais amo, e de quebra solidificar o conhecimento passando ele a diante. Espero que esta série de textos possam te despertar a curiosidade a respeito dessa linguagem.

O que é o Ruby?

Bem, não é o foco deste texto trazer todo o conhecimento de Ruby e sua filosofia. É um texto mais prático. Porém, recomendo alguns conteúdos que podem ser úteis caso você queira aprender do zero a linguagem (como estou fazendo):

Apostila de Ruby on Rails da Caelum - sim preferi começar por essa apostila, por ter uma pegada mais prática
A História de Ruby on Rails | Por que deu certo? - vídeo de uma das maiores referências de Ruby noo Brasil, Fábio Akita
Vale a pena? Ruby on Rails (feat Akita e Lucas Caton) - vídeo do canal do pessoal do DevNaEstrada
Documentação oficial do Ruby
Tutorial de Ruby

Executando um código Ruby

Bem, dedico uma seção aqui para deixar uma dica para você. Procure dar preferência, quando possível, a usar docker para execução de algumas coisas. Existem projetos, como o dockerize, em que você não precisa instalar nada na sua máquina para rodar um script, por exemplo. Foi o que eu fiz com o Ruby. Ele não vem instalado no Linux, e não gostaria de instalá-lo. Portanto, fiz uso o Docker. Segue os passos:

# num terminal zsh
docker run --name ruby_exec -v $(pwd):/home --rm -i -t -w=/home ruby:slim ruby <script>

Para facilitar sua vida, você pode criar uma função no ZSH. Eu, por exemplo, criei uma chamada ruby, que ficou assim:

# em seu .zshrc
function ruby() {
  docker run --name ruby_exec -v $(pwd):/home --rm -i -t -w=/home ruby:slim ruby $1
}

Dessa forma eu só digito no terminal ruby script.rb e pronto, ele vai executar o script Ruby para mim.

Criando uma aplicação de terminal para cálculo de IMC

Bem, o objetivo aqui é abordar:

Saída padrão de dados usando puts ou print
Entrada padrão de dados usando a função gets
Criação de sua própria função usando def
Entendendo a estrutura condicional

Antes de mais nada, gostaria de convidá-lo a acessar o repositório meu de estudos com ruby. O código para este texto é o imc.rb.

Saída de dados padrão

Bem, como o texto fala de um programador com background em JavaScript aprendendo Ruby, sabemos que em JavaScript a principal forma de saída é o famoso console.log. Em Ruby, aprendemos que há duas formas principais de mostrar um dado na tela:

puts: printa e pula uma linha
print: só printa o dado na tela, sem pular linha

puts "Hello World"

Entrada padrão de dados

Em JavaScript, dependerá de onde estamos executando nosso código. Qual o contexto? Se for Node.js, por exemplo, teremos que capturar a entrada do usuário de uma forma não muito simples. Existem bibliotecas que nos ajudam nisso, prompts é uma delas.

Já com Ruby, podemos fazer um simples gets, atribuindo para uma variável, que conseguimos capturar um input do usuário.

# uso o print para que o promp para o usuário digitar o nome
# apareça no final da linha
print "Qual o seu nome: "
nome = gets

Criando sua própria função

Para que eu consiga calcular o IMC, eu preciso da altura e peso da pessoa. Quando aprendemos a programar, aprendemos que código repetitivo colocamos em funções. Pois bem, precisamos criar uma função para mostrar um pergunta ao usuário e depois capturar a informação que ele digitar.

Com JavaScript, podemos criar funções de inúmeras formas, com função nominal, função anônima ou arrow functions. Já com Ruby, utilizamos a palavra reservada def, bem semelhante ao Python:

def get_user_input(msg)
    print msg
    return gets
end

É importante notar que em Ruby usamos o conceito de método, portanto, ao fazer suas pesquisas, se atente a essa nomenclatura.

Condicionais

Por fim, a última parte da nossa abordagem é a categorização. Sabemos que o IMC possui categorias. Estaremos usando como referência Wikipedia.

Para tanto, a decisão tomada foi criar uma função que retorna uma categoria a partir do IMC. Veja como ela ficou:

def categorize(value)
    if (value < 17)
        return "Muito abaixo do peso"
    end

    case value
    when 17.1...18.49
        return "Abaixo do peso"
    when 18.5...24.99
        return "Peso normal"
    when 25...29.99
        return "Acima do peso"
    when 30...34.99
        return "Obesidade I"
    when 35...39.99
        return "Obesidade II (severa)"
    else
        return "Obesidade III (mórbida)"
    end
end

Algumas coisas nos chamam a atenção em comparação com JavaScript:

O não uso de chaves {} para delimitar blocos. Isso ocorre pelo uso da identação
O uso da expressão end para delimitar, também, o fim de um bloco de código
E o range de dados, para delimitar um valor inicial e um valor final. Lindo demais :)

Conclusões finais

Como dito, o objetivo deste texto é proporcionar uma experiência muito prática e até superficial a respeito da linguagem Ruby em comparação com JavaScript. Espero que possa ser de auxílio em algum nível.

Por fim, não deixe de conferir o código completo no meu repositório.

Até a próxima!