ViewComponents: O Segredo para Interfaces

Todo desenvolvedor Rails já passou por isso. Você precisa criar um card simples do Bootstrap. Primeiro, você faz direto na view. Depois, precisa do mesmo card em outra página, então extrai para um partial. Até aí, tudo bem. Mas logo começam as exigências: um card precisa de um rodapé opcional, outro precisa de um título de cor diferente, e um terceiro recebe um bloco inteiro de formulário no corpo.

Para lidar com essa variação, a saída comum é injetar uma lógica pesada de condicionais dentro do seu arquivo .html.erb (o que é péssimo de ler e manter) ou criar dezenas de helpers globais. Eu já trabalhei em projetos gigantes de gestão pública e vi de perto o inferno que é ter módulos e mais módulos de helpers colidindo, difíceis de testar e que exigiam prefixos para não quebrar a aplicação inteira.

Quando o front-end vira uma zona, muitos desenvolvedores acabam acreditando que a única saída é jogar o HTML fora e inflar a stack com uma SPA em React. Não precisa. O Rails tem uma resposta muito mais simples, se você souber organizar a sua arquitetura.

A ideia central dessa aula é simples e poderosa: **a view é um objeto Ruby**, e quando você começa a tratá-la assim, tudo muda na forma como você organiza e mantém o front-end da sua aplicação. Antes de qualquer coisa, quero que você fixe os pontos que mais importam aqui: - **Encapsulamento real**: a lógica do componente fica na classe, não espalhada em helpers globais ou enterrada dentro do `.html.erb` com uma floresta de `if/else` - **Slots com `renders_one` e `renders_many`**: em vez de inflar o `initialize` com parâmetros booleanos, você declara exatamente o que o componente pode aceitar — rodapé, cabeçalho, ações — de forma declarativa e legível - **Testabilidade**: como é uma classe Ruby pura, você consegue testar o componente de forma unitária, sem precisar subir a stack inteira da requisição - **`content` como bloco principal**: essa variável reservada pelo ViewComponent é o que permite que o componente seja flexível sem perder o controle sobre sua estrutura ⚠️ O erro mais comum que vejo acontecer é continuar usando `@variáveis de instância` direto no template em vez de expô-las com `attr_reader`. Pode parecer detalhe, mas isso quebra o contrato entre classe e template e dificulta muito o rastreamento quando o componente cresce. **Minha recomendação prática:** pegue um partial que você já usa em mais de dois lugares no seu projeto atual e refatore ele para um ViewComponent essa semana. Não precisa ser o maior — começa pelo mais repetido. Você vai sentir na prática o quanto o código fica mais honesto e fácil de evoluir.