Viagem de frente para Drupal + Pattern Lab

O Pattern Lab é um tópico quente na comunidade Drupal hoje em dia, oferece muitas vantagens e promete vida fácil para designers, clientes e, finalmente, para desenvolvedores. Sendo moderno e inovador, nossa equipe certamente não poderia passar por isso, assistimos e lemos vários artigos sobre e cheios de emoção trouxeram para o próximo projeto. Uma coisa que eu notei foi que a maioria dos apresentadores tinha um conhecimento significativo de Drupal, o que não era meu caso, mas não prestei atenção naquele tempo.

Existem 3 razões pelas quais gostamos do Pattern Lab e as passamos compartilhando o que descobrimos e sobre o qual você deve prestar atenção ao adotar a tecnologia .:

  1. Abordagem baseada em componentes
  2. Desdobrando frontend e backend para que o frontend possa funcionar sem conhecer as tripas do Drupal
  3. Nice playground biblioteca padrão que pode ser mostrado ao cliente / designer para uma revisão inicial

1. Abordagem baseada em componentes

Com o aumento de frameworks frontend como React, Angular 2+, Polymer e muitos outros, é difícil imaginar a arquitetura frontal sem componentes baseada em componentes, o que, em suma, significa que cada componente possui seu próprio escopo de dados, visão e lógica do controlador, que são normalmente apresentado com JS, CSS e JSON ou YML, o que significa mudanças dentro de um componente não afetará estilos e lógica interna de outros.

Então, o componente normal parece ser o seguinte:

O Laboratório de Padrões recomenda agrupar ativos em pastas com base na metodologia de design Atomic e fornece um ótimo suporte para os dados falsos isolados do componente, dando-nos a liberdade de escolher nossas próprias ferramentas para lidar com o escopo JS e CSS, que é um movimento inteligente no sentido de que não podem prever o pilha preferida que normalmente usamos para isso.

HTML: não há muito de complicações cerca âmbito HTML para que apenas criar próprio twig modelo para cada componente e, em seguida, usá-lo sempre que quiser através de incluir e incorporar directivas galho passando os valores dos parâmetros apropriados.

Dados de componentes: podemos escolher o formato JSON ou YAML para dados falsos de componentes. Ambos são ótimos e existem maneiras fáceis de migrar rapidamente de um para o outro, embora escolhemos YAML à medida que parece mais limpo:

Exemplo JSON vs YAML

Esses arquivos são usados ??exclusivamente para renderizar componentes na UI do Pattern Lab e nunca aparece na produção. Podemos definir múltiplas instâncias de dados falsos para cada componente simplesmente alterando o nome do arquivo postfix separado com o símbolo tilde que o torna super útil para testar e demonstrar estados diferentes do componente.

Estrutura do arquivo de dadosExemplos de diferentes estados de componentes

Existe um arquivo de dados global que é acessível em toda a árvore de componentes, por isso é uma boa idéia colocar, por exemplo, itens de menu globais ou links de rodapé lá. O arquivo de dados globais normalmente é acessado por esta localização: pattern-lab/source/_data/data.yml .

Cuidado : os únicos dados que são usados ??para renderizar um padrão são seus próprios dados e dados globais. Se incluímos ou incorporamos o componente_1 dentro do componente_2, temos que colocar dados para o componente_1 no arquivo de dados do componente_2. Se você quiser evitar esse trabalho manual, confira este plugin: Plugin de Herança de Dados .

CSS : usamos a combinação SCSS + SSMACSS + BEM que nos deu uma maneira de isolar CSS através da convenção de nomenclatura de classe. Eu não vou entrar em detalhes aqui, mas você pode dar uma olhada em alguns truques SCSS para conseguir isso. Também estou olhando para a frente em Módulos CSS para projetos futuros.

JS : é a parte mais complicada e incide em várias tarefas.

Bundler de módulos : o Drupal 8, por padrão, fornece uma maneira muito legal de anexar o CSS e o JS do componente à página, introduzindo um conceito de biblioteca que permite especificar diferentes pacotes na configuração do Drupal e, em seguida, inclua apenas aqueles deles na página que são realmente necessários. Uma definição de biblioteca pode ser assim:

E, em seguida, tem que ser anexado ao modelo por qualquer um dos métodos descritos na documentação aqui .

O problema pode aumentar se o accordion.js do nosso exemplo tiver sua própria dependência dentro. Não é uma boa idéia apenas colocar essa dependência no mesmo nível no arquivo de configuração porque, neste caso, devemos copiá-lo em todos os lugares. E se existem vários níveis de dependências, as coisas se tornam muito confusas.

Para resolver isso, usamos o bom Browserify antigo, e o Webpack também pode ser uma opção. Para fazê-lo funcionar, require módulo dentro do nosso arquivo JS e permitamos que o Browserify seja responsável por nós por meio de uma tarefa de gulp . É assim que o nosso arquivo javascript de componente de overlay começa:

Outra questão é que o Pattern Lab não conhece nada sobre o conceito de bibliotecas do Drupal e, se queremos que nossos componentes funcionem dentro do sandbox, devemos adicionar todas as mesmas bibliotecas no arquivo pattern-lab/source/_meta/_01-foot.twig para ter certeza nosso JS é acessível em todas as páginas dentro do ambiente de teste.

Para simplificar as coisas no começo, acabamos de criar um grande pacote JS e anexado a Drupal e Pattern Lab. Felizmente, fomos capazes de manter o pacote relativamente pequeno e não havia muito espaço para dividir JS entre as páginas, então a nossa solução temporária tornou-se permanente 🙂

Interação de componentes : uma vez que temos todos os componentes isolados, temos que definir uma maneira como eles se comunicam entre si.

Imagine que temos um componente de cabeçalho e um menu de barra lateral que desliza – em qualquer botão de tempo é pressionado no cabeçalho.

Podemos fazer a lógica dentro do cabeçalho JS (dentro de um manipulador de eventos de cliques), mas, assim que nos esforçamos para uma arquitetura vagamente acoplada , decidimos usar um padrão de mediador simples no lugar e escolher Redux . É muito popular e abordei alguns dos seus aspectos antes.

Um problema para não esquecer é que o Redux, por padrão, liga a todos store assinantes da store , que não queremos acontecer porque não temos o Shadow DOM e o mecanismo inteligente de detecção de mudanças aqui como Reagente, então usamos uma extensão chamada redux-watch e envolveu nosso método de subscribe da maneira que apenas o reducer necessário é invocado:

Se a terminologia parecer confusa, a documentação do Redux pode ser útil.

Comportamentos Drupal : Se você nunca trabalhou em projetos Drupal, você deve se familiarizar com o conceito Drupal Behavior . Em suma, no mundo do Drupal, não podemos confiar em nenhum evento de carregamento de documentos, pois, a qualquer momento, o Drupal através do AJAX pode substituir qualquer parte do HTML com a nova versão e a única maneira de saber sobre isso é através da chamada do método attachBehaviors .

Então, regra de ouro aqui:

Sempre envolva seu código JS com o objeto Drupal.behaviors.yourName

Exemplo de comportamento

Embora o Pattern Lab não conheça nada sobre os behaviors e devemos anexar manualmente drupal.js do núcleo do Drupal a todas as nossas páginas do Pattern Lab dentro pattern-lab/source/_meta/_01-foot.twig arquivo pattern-lab/source/_meta/_01-foot.twig :

Código para anexos de drupal.js

Juntamente com ready.js . Isso já está incluído no tema Emulsify Drupal, que abordarei mais tarde, então, provavelmente, você apenas precisa descomentar as linhas de código apropriadas.