Além das ferramentas.

Nós, como membros da comunidade de desenvolvimento web, frequentemente nos definimos pelas ferramentas que usamos. Sou desenvolvedor React ou sou desenvolvedor Vue. Por mais excelentes que sejam essas ferramentas, pensar apenas dentro desse ecossistema é limitador. Somente pensar em uma única estrutura canaliza seu processo de pensamento para resolver as coisas de uma maneira específica que é inversa. Em vez de pensar em como as ferramentas podem resolver nossos problemas, acabamos tentando adaptar nossos problemas às nossas ferramentas.

O que isso significa é que estamos perdendo uma grande oportunidade. O cenário de desenvolvimento em mudança com novas ferramentas e estruturas não está deixando você obsoleto. Para o carpinteiro, a serra elétrica não torna a serra manual inútil. Tampouco invalida seu conhecimento de diferentes madeiras e técnicas de construção.

O front-end é definido por seus problemas.

Entenda nossos problemas, pegue nossas ferramentas, antigas e novas, e explore diferentes abordagens para resolvê-los. Então, quando você recebe um novo aplicativo, pode acessar sua caixa de ferramentas profunda e escrever um ótimo código.

---

O primeiro artigo desta série visa fornecer perspectivas sobre os problemas e objetivos do desenvolvimento front-end. Na parte 1, discutiremos como pensar sobre a composição de componentes. Na parte 2, forneceremos exemplos concretos com o Code.

Composição do componente

Por que se preocupar com componentes:

Antes de começarmos, devemos pensar sobre o que é “bom código”. O código:

• faz o que queremos (funcional) ,
• fácil de escrever (velocidade do desenvolvedor) ,
• fácil de ler (sustentável) ,
• faz bem (pequeno, rápido e confiável) .

Os problemas

Escrever HTML, CSS e Javascript no passado costumava ser um pesadelo. Basta dizer que houve um erro no site em que você está trabalhando. Há um botão que deve iniciar um modal / pop-up, mas o botão estava no tamanho errado e o pop-up não estava aparecendo.

Como resolveríamos isso? Examinaríamos o HTML para encontrar o botão que estávamos vendo. Em seguida, procuramos o arquivo com o CSS que seleciona o botão mais importante e fazemos algumas mudanças de estilo. Por fim, procurávamos nos arquivos Javascript procurando algo que selecionasse esse botão e veríamos o que estava errado.

O problema? Código de espaguete pouco claro. Tivemos que vasculhar todos os nossos arquivos, nem mesmo sabendo onde procurar apenas para editar a pequena parte que nos importava.

A solução

Componentes são as ferramentas criadas para quebrar essas pequenas partes do nosso site.

• Partes menores de códigos relacionados significam que as coisas são mais fáceis de encontrar, ler e manter.
• Os componentes também são reutilizáveis: Desenvolvimento mais rápido (princípio DRY)

Embora pareça bom em teoria, na prática, existem muitos problemas que podem surgir.

• Os próprios componentes podem se tornar muito complexos. (Como mantemos nosso código simples?)
• Nossos componentes não são muito reutilizáveis. (Como projetamos componentes reutilizáveis?)

Artigo Roteiro

Para resolver esses problemas, precisamos de princípios pelos quais projetar componentes. A seguir estão os tópicos sobre os quais falaremos.

1. Níveis de preocupação separados
2. Pensando em Composição
3. Projetando para Reutilização

Níveis de preocupação separados

Problema: Como impedir que nossos componentes sejam muito complexos?

A complexidade geralmente vem de ter que lidar com muitas preocupações. Mas, embora a quantidade seja um fator que contribui, nem sempre é o caso de menos preocupações serem melhores.

Por exemplo, como discutido anteriormente, as pessoas tentaram dividir marcação, estilo e script em três preocupações por um longo tempo. No entanto, essa separação realmente torna o código mais complexo. Essas são três preocupações diferentes, MAS, elas são altamente relacionadas pelo mesmo objetivo: criar um único elemento / componente. Essas três preocupações estão em um único nível de preocupação.

E muitas ferramentas reconheceram essa realidade. Toda estrutura anexa principalmente ações diretamente à marcação (mesmo o HTML / JS baunilha possui uma API baseada em atributo para anexar scripts à marcação). O Vue usa componentes de arquivo único, agrupando a marcação, o estilo e o script de um componente no mesmo arquivo. O CSS de vento de cauda usa classes de utilitário para misturar o estilo com a marcação.

Não é mudar as preocupações que dificulta a codificação. É a mudança entre os níveis de preocupação.

Níveis de preocupação

Preocupações em nível organizacional (alto)

• Como vemos o problema?
• O que precisa ser feito?
• Como delegamos responsabilidades?

Preocupações em nível de abordagem (meio)

• Quais problemas / objetivos menores existem?
• Como abordamos o alcance desses objetivos?

Preocupações em nível de implementação (baixa)

• Sabemos exatamente o que queremos fazer.
• Como fazemos isso.

Exemplos
Uma preocupação organizacional pode corresponder a uma visão específica no seu aplicativo de blog. No nível mais alto, você precisa fornecer ao usuário conteúdo, uma maneira de navegar para outro conteúdo, uma maneira de compartilhar e ler comentários. Um componente que funciona nesse nível de preocupação pode ser um componente de exibição. O componente View delega essas três tarefas para outros três componentes: a barra de navegação (para navegação), a área principal (para conteúdo) e o rodapé (para comentar).

Agora a barra de navegação, rodapé e barra lateral têm preocupações respectivas, mas que tipo de preocupação são elas? A principal responsabilidade da Navbar é listar a estrutura do site. Se considerarmos ou não, decidimos fazer com que esse componente se preocupe com a organização, a abordagem ou a implementação depende puramente da complexidade. Poderia ser apenas sobre implementação, se for apenas uma lista não ordenada de links e não houver preocupações menores com as quais lidar. Talvez desejemos ter vários níveis de profundidade em nossa navegação. Talvez faça sentido descrever nossa abordagem para resolver o problema adicionando um componente filho à barra de navegação responsável por exibir cada submenu. Deseja revelar um carrossel e um vídeo? Nesta fase, pode fazer sentido também ser organizacional.

Por que manter os componentes em níveis? Em primeiro lugar, é uma cascata natural de responsabilidade. Se eu estiver olhando para o comportamento de um componente filho, sempre posso começar mais alto e ir mais fundo, nível por componente, e ter uma boa compreensão do que faz o que e como. Isso contrasta com as preocupações organizadas pelo tipo de tarefa que eles executam, como arquivos em pastas marcadas com componentes, ações, redutores, estilos etc. Quer saber onde está algo e como editá-lo? Melhor saber como funciona com antecedência.

A principal razão é que ele mantém problemas relacionados juntos. Quando você estiver editando algo em um nível de preocupação, provavelmente tocará outras coisas no mesmo nível. Melhor mantê-los perto. Possivelmente mais importante, esses níveis mantêm as preocupações não relacionadas de fora! Imagine ter um código no nível Visualizar / organizacional como um ouvinte de rolagem que controla algo na seção comentário / rodapé. Imagine olhar para o componente do rodapé e não conseguir encontrar nada que possa produzir o bug que você encontrou. Isso é complexidade.

Por fim, o objetivo de descrever os níveis de preocupação é permitir que você vincule seus componentes à estrutura do seu problema. Existem outros tipos e níveis de preocupação também! Mas esses são os três mais comuns e úteis ao projetar sua base de código.

Causas comuns de quebrar preocupações

• Modularização excessiva : às vezes um componente pode ter três partes, mas são todos simples. Uma boa regra geral é que o modelo, o código e o estilo do componente ocupem cerca de 1 coluna de página inteira da tela. Mais e você deve pensar em terminar.
• Aderindo muito a uma regra básica de programação: a arquitetura Flux com adereços desativados e eventos ativos funciona em muitas circunstâncias. Mas às vezes não. Não se force para cima ou para baixo em 5 camadas.

Pensando em Composição

Problema: Quando devo fazer um esforço extra para tornar um componente reutilizável? E de que maneira?

Ao codificar, geralmente existem dois tipos diferentes de código que escrevemos. Há código independente de aplicativo e, em seguida, há código específico de aplicativo. Coisas como pequenos elementos, funções auxiliares, bibliotecas geralmente são agnósticas ao aplicativo em que estão. Consequentemente, elas devem ser projetadas para serem reutilizáveis. E há uma lógica específica para o aplicativo que você está construindo. Coisas que provavelmente não serão transportadas para nenhum outro lugar.

Aqui está uma abordagem para escrever componentes.

Blocos, composições e vistas .

• Blocos são os componentes de uso geral que você pode usar em qualquer aplicativo. (por exemplo, botão)
• As composições são componentes “específicos da aplicação”. (por exemplo, Feed de notícias)
• As visualizações são os componentes específicos de aplicativos de alto nível que representam mais ou menos a área principal de um site / aplicativo. (por exemplo, página inicial)

Em geral, os blocos são usados ​​para criar composições, que são usadas para criar vistas.

Blocos → Composições → Visualizações

Blocos

Blocos são pequenos componentes de uso geral que podemos usar em qualquer lugar e em qualquer lugar dentro de nossos aplicativos. Também podemos construir blocos mais complicados com nossos blocos menores. O principal dos blocos é que precisamos projetá-los para serem reutilizados de maneira geral. Flexibilidade é a chave!

Exemplos de blocos

• Botão (bloco de elemento)
• Colunas (bloco de layout)
• Fornecedor de dados (bloco de recursos)
• Modificador de animação (blocos modificadores)

Mais sobre tipos de blocos na próxima seção

Composições

Composições são coisas que fazemos usando blocos específicos a um propósito específico. Eles podem ser reutilizáveis ​​no seu aplicativo, com pequenas diferenças entre as páginas, mas você deve fazer isso de maneira geral. Faça abstrações apenas quando seu aplicativo precisar.

Exemplos:

• Feed de Notícias do Facebook
• Seu componente de cartão postal projetado

Visualizações

As visualizações geralmente acabam descrevendo layouts e, como tal, podem ser reutilizáveis ​​no sentido de que podem ser usadas para muitos contextos diferentes. Geralmente, no entanto, você extrai layouts como blocos.

Os benefícios

O principal benefício desse tipo de composição é que ele se encaixa na separação dos níveis de preocupação. Por exemplo, com um View, você se preocupa principalmente com a organização. Com uma composição, você estará pensando em abordagens de comportamento. Naturalmente, os blocos executam uma implementação de baixo nível: acessando o DOM e usando recursos específicos da estrutura, como portais, ligação de dados bidirecional, ganchos, etc.

Em seguida, ajuda a organizar sua base de códigos. Os blocos serão bibliotecas de componentes compartilhados entre plataformas. A raiz da pasta de composições terá todas as composições de alto nível, com seus componentes filhos dentro dos subdiretórios. A pasta Views pode se organizar de maneira a corresponder às rotas.

Design de bloco: melhorando a reutilização e a legibilidade

A chave para a reutilização é a flexibilidade. Você reutilizará um bloco quando ele atender às suas necessidades em uma circunstância diferente. Geralmente, há uma troca entre a quantidade que um bloco faz e a sua flexibilidade. Um bloco que faz muitas coisas pode ser ótimo para uma situação, mas não necessariamente para outra. Um bloco deve fazer o máximo possível, mas comprometer o usuário com o mínimo possível.

As duas principais coisas que precisamos controlar no front-end é como as coisas se parecem e como se comportam. No mundo React, as pessoas tentam fazer isso criando Componentes de Apresentação (como as coisas parecem) e Componentes de Contêiner (como as coisas se comportam). Embora seja uma boa divisão, na maioria das vezes, isso geralmente não é granular o suficiente para ser flexível. A apresentação, por exemplo, tem muitos subproblemas: contexto / marcação, estilo, posicionamento etc. Como tal, precisaremos examinar muitos outros tipos …

Abordaremos apenas vários tipos diferentes de componentes aqui, como eles funcionam dentro do contexto de pensar sobre composição. Para exemplos concretos de como projetar e implementar blocos, aguarde a Parte 2.

Responsabilidades dos componentes de apresentação

Eles são responsáveis ​​por:

• Marcação – O HTML que é mostrado.
• Estilo – O CSS para exibir o HTML
• Manipulação básica de eventos / Gerenciamento básico do estado da interface do usuário – Gerenciamento do estado básico e ações como alternar, passar o mouse, clicar, etc.

Algumas pessoas diriam que você deve tentar manter seus componentes puramente funcionais. Só faça isso se fizer sentido para um desempenho crítico. Isso tornará seu código mais complexo se você o artificialmente funcional.

Aqui estão três tipos de componentes de apresentação.

• Elementos
• Layouts
• Modificadores visuais

Elementos

Elementos são o bloco canônico. Pedaços de marcação que você pode reutilizar em qualquer lugar do aplicativo. Eles normalmente envolvem apenas um elemento HTML real, mas têm adereços extras para uma personalização mais útil.

Componentes de layout

Componentes de layout são uma estratégia de estruturar seus componentes. Os componentes de layout são, como o nome sugere, apenas para o layout do conteúdo.

Embora o Layouts possa normalmente ser alcançado com nomes de classes CSS, que é a abordagem comum em estruturas como Bulma ou Bootstrap, se você deseja um melhor encapsulamento / deseja interromper o css vazando em seus layouts por meio de classes globais, o uso do estilo com escopo dentro de um componente pode funcionar melhor.

Com abordagens como CSS em JS e CSS Variables, também podemos gerenciar coisas de layout que não podemos fazer apenas com css puro. Podemos vincular valores css a variáveis ​​/ objetos javascript. Podemos fazer coisas como fazer consultas de elementos (designs responsivos que dependem da largura do elemento e não apenas da largura da tela), controlar variáveis ​​como intervalos e preenchimento de adereços, etc.

Modificadores visuais

Modificadores visuais são componentes que você pode usar para envolver outros componentes e fornecer recursos específicos, como efeitos de foco, animações etc.

Os modificadores visuais são mais claros, flexíveis e reutilizáveis ​​que a maioria das estratégias tradicionais de HTML / CSS. Uma interface de suporte oferece a você o poder do JavaScript para controlar esses modificadores, permitindo controlar as velocidades de transição, ou passar sobreposições de estilo, etc.

Componentes para contêineres

Os componentes do contêiner são os componentes “lógicos” e comportamentais. Eles usam ganchos do ciclo de vida, estado local, gerenciamento de estado etc. No contexto de blocos, eles fornecem padrões reutilizáveis ​​para gerenciamento de estado, interações do usuário ou comportamentos de manipulação.

Eles são responsáveis ​​por:

• Gerenciamento de Estado
• Manipulação de dados / Lógica
• Comunicação de dados

Existem dois tipos principais de componentes de contêiner:

• Componentes do modificador comportamental
• Componentes de Recursos

Componentes do modificador comportamental

Um modificador comportamental é um componente que ajuda a fornecer uma pequena parte da funcionalidade. Eles geralmente fornecem marcação mínima / puramente lógica ou são componentes sem renderização.

Exemplos:

• Arrastar e soltar lista de reordenação
• Consulta de elemento / Resposta visual

Componentes de Recursos

Um padrão comum que aparece no desenvolvimento front-end é o gerenciamento de dados. Haverá momentos em que você estará recebendo e lidando com dados com as mesmas intenções. Por exemplo, você precisará:

• Obter dados do servidor
• Crie um carregador / girador
• Resolver erros
• Mostrar dados

Imagine ter 4 tipos diferentes de recursos de dados. Se você integrou firmemente a lógica às visualizações, teria que reescrever a mesma lógica 4 vezes (com parâmetros ligeiramente diferentes).

Um componente de recurso pode ser uma boa maneira de se comunicar com seu gerenciamento de estado. Em vez de reescrever ações de “despacho” para cada componente que precisa consumir esses dados, você pode fazer com que o componente de recurso faça o trabalho pesado.

Widgets

Blocos são compostáveis, portanto, obviamente, podemos criar blocos mais complexos a partir de blocos menores. Você costuma reunir vários componentes para formar um pequeno componente utilizável, como guias ou uma barra de ferramentas. Esses widgets predefinidos incorporam diferentes padrões de interface do usuário que facilitam a criação de interfaces complicadas.

Os widgets costumam fazer muitas coisas e, consequentemente, geralmente não são tão flexíveis. Uma boa estratégia para criar widgets reutilizáveis ​​é ter a marcação padrão que um consumidor do seu bloco pode substituir posteriormente, mas ainda assim se conectar aos dados e eventos do componente. Outra é tornar muitos dos recursos opcionais / ocultáveis.