Receita para front-end rápido

– 7 minutos de leitura
rant

Meu maior defeito como programador sempre foi ser lerdo no front-end. Apesar de no meu cargo estar escrito Programador Fullstack o desenvolvimento no back-end sempre foi o meu “forte” enquanto no front sempre “empurrei com a barriga”.

Após meses estudando o tempo que eu demoro para construir aplicações front-end, cheguei em um monte de conclusões que podem te ajudar a entender como você mesmo(a) pode estar sofrendo dos mesmos males e como se tornar um(a) desenvolvedor(a) mais ágil sem sacrificar os seus valores.

Vou listar todos os passos que me fizeram deixar de ser um desenvolvedor lento e no final eu vou postar uma receita e um link para acessar o meu repositório modelo, onde eu tomo como base para todas as aplicações front-end que eu desenvolvo.

Primeiro passo.

1. Utilize só o NPM

Não perca tempo usando outros gerenciadores de pacotes como yarn, bun, pnpm e deno, pois o ecossistema Javascript é muito bagunçado e muitos pacotes que dependem do React podem falhar quando o gestor não é o npm. Dois exemplos são vite e react-router.

Eu já cansei de ver projetos parando de funcionar devido a alguma diferença no ambiente de execução. Desde que voltei a usar npm eu nunca mais tive dor de cabeça.

Jamais utilize deno para projetos front-end, o repositório de pacotes deles carece de muitas dependências em cima do ReactJS e o deno só serve para projetos que rodam no lado do servidor. Além disso, as dependências do repositório do NPM não são compatíveis com o deno, pois todas esperam compatibilidade com o node. Já tentei fazer projetos front-end com o deno e só ganhei dor de cabeça.

2. Repositório modelo

Não perca tempo rodando create-react-app toda vez que você começa um projeto novo. Crie um projeto do jeito que você gosta uma única vez e coloque-o num repositório no GitHub como modelo, assim toda vez que você quiser começar um projeto novo basta clonar o repositório modelo e desenvolver. Você quase sempre precisa:

Então, por que não pular essas etapas e colocar tudo num repositório? Pegue as bibliotecas que você está mais familiarizado e coloque-as no seu projeto base.

Dica: Lembre-se de atualizar o seu repositório modelo periodicamente para manter as dependências e práticas atualizadas.

3. Configurações de rotas

Sempre utilize frameworks com configurações de rotas implícitas como o NextJS ou o React Router.

Um exemplo de convenção que facilita muito a minha vida é a configuração por meio do sistema de arquivos do React Router.

Muito mais fácil do que desenvolver minha própria lógica de renderização. Um exemplo de projeto que segue essa convenção é o front-end do Zetsu:

routes
├── admin.file-new.tsx
├── admin.files-listing.$sha1.edit.tsx
├── admin.files-listing.$sha1.tsx
├── admin.files-listing.$sha1.view.tsx
├── admin.files-listing.tsx
├── admin.images-listing.tsx
├── admin.tsx
├── auth.tsx
├── _index.tsx
└── logout.tsx

Não precisei criar:

Não preciso olhar a fundo no código para saber como e onde novas telas são criadas.

Eu simplesmente estou velho demais para esse tipo de coisa:

<Routes>
  <Route index element={<Home />} />
  <Route path="about" element={<About />} />

  <Route element={<AuthLayout />}>
    <Route path="login" element={<Login />} />
    <Route path="register" element={<Register />} />
  </Route>

  <Route path="concerts">
    <Route index element={<ConcertsHome />} />
    <Route path=":city" element={<City />} />
    <Route path="trending" element={<Trending />} />
  </Route>
</Routes>

Rotas declarativas como essas fazem com que projetos fiquem bagunçados e difíceis de acompanhar, pois vai do bom senso de cada desenvolvedor as pastas onde cada configuração é feita. Sem falar que é difícil localizar a rota que você quer dar manutenção porque as rotas podem ser configuradas em diversos lugares diferentes e podem não seguir nenhuma hierarquia.

4. Cliente OpenAPI

Não perca mais o seu precioso tempo criando interfaces typescript a partir de documentações do Swagger ou configurando o seu axios, pois existem bibliotecas que já fazem isso por você.

Mas, e se as tipagens estiverem erradas?

Problema do back-end!

Todo desenvolvedor back-end sabe onde o sapato aperta, se ele sabe que uma propriedade pode ser nula, então ele deveria deixar isso documentado na API, o mesmo vale para propriedades obrigatórias. O desenvolvedor front-end não tem bola de cristal para adivinhar quais dados são obrigatórios e quais podem ser omitidos. Eu tenho muita raiva de gente que trabalha no back-end e não deixa essas coisas documentadas, é tão simples! É só colocar a tipagem na linguagem que você estiver usando:

<?php
class SimpleDTO {
    public function __construct(
        public ?int $id,
        public readonly \DateTimeImmutable $createdAt,
        public string $description,
    ) {}
}

Qualquer biblioteca de OpenAPI documenta isso para você! Você só precisa se preocupar com a tua linguagem. Deixe tudo “redondinho” no back-end que as tipagens na documentação vão aparecer corretas!

Dado que o back-end esteja devidamente documentado com OpenAPI (o que é padrão nos dias de hoje), você não precisa mais perder o seu tempo copiando as interfaces de respostas uma por uma. Basta usar um gerador de tipos para Typescript e importá-los para dentro do seu projeto, você poupa tempo e discussões com os colegas sobre “onde vão deixar as interfaces” e “como vão documentar as interfaces”.

5. Telas prontas

Não perca seu tempo criando telas do zero! Prefira bibliotecas com telas prontas no estilo “é só pegar e usar”. O Toolpad do Material-UI é um exemplo:

Vai desenvolvedor um CRUD? Um dashboard? Uma tela de login? Tudo isso já está pronto, é só você usar. Precisa de uma identidade visual com as cores e logos da empresa? É só você alterar o tema do Material-UI. Você não precisa provar para ninguém que sabe programar em React, você só precisa entregar um produto que funcione!

Existem várias bibliotecas parecidas que seguem o mesmo princípio:

Algumas são pagas enquanto outras gratuitas, mas o ponto é: construir telas para a maioria das aplicações é o mesmo que reinventar a roda. Toda empresa quer fazer diferente, mas vai de você oferecer um produto sob medida com componentes prontos.

Essas telas vêm com componentes onde a tua única preocupação é preencher as props react delas. Você não precisa se incomodar com responsividade, funcionalidade, cores, lógica de implementação e afins, só a regra de negócio em si.

Conclusão

Sempre que puder, utilize frameworks opinativos1 e convenções prontas, não perca seu tempo reinventando a roda em projetos novos, pois você vai perder tempo demais com coisas que não dão retorno ao invés de simplesmente produzir. Utilize projetos não sérios se você está a fim de brincar com as tuas habilidades. Procure por convenções porque elas existem por algum motivo.

Com essas práticas você pode economizar várias horas de configuração inicial em cada projeto e também horas no tempo total de desenvolvimento ao reutilizar componentes e padrões testados.

Eu só sei que estou velho demais para este tipo de coisa: escrever tudo do zero, desenvolver meus próprios padrões, eu não aguento mais. Eu quero que você aprenda de alguma maneira com esse artigo e não cometa os mesmos erros que eu.

Se você quiser, aqui está o modelo de repositório que eu utilizo em projetos novos de front-end:

Eu posso atualizar esse modelo conforme as minhas preferências forem mudando e você também pode fazer o mesmo. Crie o seu modelo e deixe-o pronto para novos projetos, se você juntar todas essas práticas você vai eliminar um monte de barreiras e vai começar a produzir logo de cara. Boa sorte e um grande abraço!

  1. do inglês opinionated que significa dogmático, com convenções próprias, com opiniões definidas. ↩︎