Reaproveitando código com Twig Template no Symfony
As vezes nos preocupamos demais com o back-end. Sim, ter um back-end organizado seguindo padrões de projeto é importante. Mas, quanta atenção demos ao código do front-end?
O código das views é tanto código quanto o dos controllers e dar uma atenção especial ao front pode ser o diferencial na manutenibilidade do sistema.
Front-end?
Nosso sistema TikTok® tem, até o momento, 3 telas. A que mostra os dados de um funcionário:
A que exibe o formulário para adicionar um funcionário:
E, a página inicial:
E todas funcionam como deveriam. Perfeito, certo? Não! Há muito tempo, software deixou de ser um sinônimo de funcionalidade e cada vez mais se torna funcionalidade com estilização.
O cliente não vai olhar o código bonito que fizemos, os controllers bem isolados cada um com sua responsabilidade. Por mais que isso afete a manutenibilidade do sistema e, por consequência, o bolso dele diretamente.
Clientes, usuários, etc, enxergam telas! Ou seja, precisamos de telas mais bonitas se quisermos que o sistema TikTok® seja aceito pelos usuários.
Bootstrap
O objetivo não é que nos tornemos todos desenvolvedores front-end (embora seja bom). Tanto porque assim como qualquer área do desenvolvimento, possui diversas ramificações e não cabe no escopo do blog aprofundar nesses conceitos.
Mas, não se aprofundar em front-end, hoje em dia, não é desculpa para entregar softwares feios. Bibliotecas CSS como Bulma, Pure CSS, Materialize e o famosíssimo Bootstrap surgem justamente pra que a gente consiga agregar um visual aceitável ao projeto dominando apenas um conjunto de classes =)
Começando com temas
No nosso caso, faremos uso do Bootstrap por ser mais famoso. E, para nossa alegria, além de existir bibliotecas css, existem templates dessas bibliotecas!
No caso do Bootstrap, existe uma galeria de templates gratuitos. Onde temos disponíveis todo o html com as classes certas já aplicadas, precisamos apenas escolher um tema e nos basearmos nesse html.
Como nosso sistema TikTok® é um sistema de gestão, vamos ficar com o tema SB Admin 2:
Baseado no Bootstrap 4, a ultima versão da biblioteca.
Mãos na massa
Agora que temos nossa biblioteca, precisamos puxar dela o que vamos utilizar no nosso projeto.
É comum que bibliotecas venham com mais arquivos do que a gente precisa. No nosso caso precisamos apenas do menu lateral, e dos componentes de formulário.
Puxando só o necessário
Temos todo esse HTML no arquivo forms.html disponível na pasta pages dentro do zip do nosso tema.
Nessa pasta ficam guardados todos os exemplos do tema com aplicações das classes.
Além dessa, temos as pastas dist com os CSSs JSs e vendor com as dependências do tema que precisaremos deixar disponíveis para o html renderizado na tela.
Integrando o tema com o Symfony
Todo arquivo publico, no Symfony 4, fica na pasta public, então é só jogar essas pastas em public:
Agora é só ser feliz e aplicar o html no projeto, começando pelo novo.html.twig:
Perfeito, com isso a cara da nossa tela já fica bem melhor:
Mas, ainda pode dar uma melhorada, seria legal aproveitar o menu lateral do tema também:
Juntando tudo temos:
Perfeito, agora é só fazer a mesma coisa para a página que exibe o funcionário:
E, com os mesmos arquivos CSS e JS da página de formulário, temos:
Perfeito, temos as duas telas já com um layout bem apresentável e responsivo!
Reaproveitando código
Nesse ponto do sistema, acabamos de cometer um gigantesco crime como desenvolvedores que, por ter ocorrido no front-end da aplicação, passou despercebido.
Código repetido é o maior indicio de problemas de manutenção dentro de um sistema. Quando repetimos muitas vezes um bloco de código no back-end sabemos que precisamos extrair um método ou algo do tipo.
Mas, no front-end, o caos acaba reinando e deixamos que muitos blocos de código se repitam. No nosso caso, repetimos o cabeçalho com a inclusão dos arquivos CSS, o rodapé com o fechamento das tags e a inclusão dos arquivos JS, além do menu lateral que é igual pra todas as páginas!
Problemas de manutenção
Se algo muda, por exemplo, no menu lateral precisaríamos alterar 2 arquivos na aplicação, o mostra.html.twig e o novo.html.twig. Se o sistema tivesse 40 telas seriam 40 pontos de alteração.
Beleza, mas o que fazer?
Uma possível solução seria separar um arquivo twig para cada pedaço de código que se repete e dar includes desses pedaços, assim como é comum se fazer em PHP.
Mas, estaríamos invertendo a lógica! Perceba que o que está acontecendo, não é uma simples repetição dos código que precisam ser reaproveitados para garantir a manutenção.
Temos uma estrutura de página definida! Uma base da tela, que contém todos os arquivos CSS, JS e o menu lateral.
O que muda de uma tela pra outra é o conteúdo dentro da tag:
<div id=”page-wrapper”>
Enxergando além com Twig
Nossa lógica deveria ser construir um único arquivo que fosse um template para os demais. Deixando toda estrutura das páginas do sistema concentradas em um único ponto.
Em Symfony, esse arquivo tem um nome comúm: base.html.twig. E, já até veio por padrão quando instalamos o Twig:
O framework costuma sempre nos direcionar para as boas práticas e esse tipo de arquivo padrão é um grande indício disso.
Criação de blocos para sobrescrita
Aqui já temos uma estrutura bem definida de html, com blocos onde podemos injetar conteúdo nas sub páginas.
O que torna a coisa muito mais dinâmica pois, caso haja a necessidade de adicionar um arquivo javascript ou CSS específico para uma página, podemos utilizar esses blocos!
Assim, no bloco body, podemos deixar apenas o que vai mudar de uma página para outra, mantendo a estrutura consolidada:
Herança de Twig
Perfeito, já temos nossa base, podemos limpar nossos arquivos e deixar dentro deles só o que muda realmente:
Mas, ainda falta indicar que esse arquivo depende diretamente do base.html.twig.
Da mesma forma que no back-end temos herança para indicar uma relação muito grande entre duas entidades, também temos herança no Twig para indicar essa relação!
Inclusive, utilizamos a mesma palavra reservada extends:
{% extends 'base.html.twig' %}Sobrescrita de bloco
A partir do momento que herdamos de um outro template, com Twig, temos disponível todos os blocos declarados no template pai!
Ou seja, para que possamos sobrescrever o body nesse arquivo, basta declarar novamente o bloco e injetar o conteúdo:
Se, por algum motivo, quiséssemos tornar os títulos dessa página um pouco maiores, bastaria adicionar no bloco stylesheets declarado no base:
Daqui pra frente, é só aplicar a mesma estrutura nas outras páginas index.html.twig e mostra.html.twig =)
Aqui já fica claro o poder que temos com Twig. Além de garantir legibilidade e estar muito bem integrado ao Symfony, conseguimos trabalhar o front-end com boas práticas e garantir a manutenibilidade nesse lado da aplicação também!
Próximos passos
Agora que temos nossas views bem organizadas, o sistema está mais bem preparado para expansão.
No próximo post vamos terminar as entidades Hora e Projeto, falando sobre relacionamento de entidades com doctrine!
Se você quer saber mais sobre temas e se aprofundar nos Forms do Symfony, tem um post aqui no blog ensinando a implementar o tema do Bootstrap =)
E ai, o que acharam da herança com Twig? Conhece algum caso de uso legal? Compartilha com a gente aqui =)
Ah! O código pronto desse post você pode encontrar versionado no meu git!
