1. 🔰 Contexto
Primeiramente gostaria de dizer que esse post será longo, mas prometo que valerá bastante a pena 😊
Recentemente participei de um processo seletivo onde o desafio era desenvolver um CRUD (Create, Read, Update, Delete) utilizando React. Apesar de eu não ter avançado, decidi documentar todo o processo, desde sua concepção até os aprendizados.
Espero que essa documentação detalhada ajude outro desenvolvedor no futuro, incluindo eu mesma (pois sempre utilizo meus próprios códigos como documentação ou para fazer algo diferente). Então vamos ao processo...
2. 📋 Requisitos do desafio
O teste consistia em desenvolver um CRUD bem simples, a empresa forneceu algumas informações que precisavam ser seguidas a risca:
- Seguir o layout criado no Figma que havia sido concedido pela empresa (quanto mais parecido com o layout, melhor; se você pensou em pixel perfect, acertou!);
- Além de seguir a risca o layout disponibilizado pela empresa, todos os fluxos do CRUD eram necessários (mas cada tela continha uma pequena instrução de como deveria funcionar 😅);
- Era imprescindível que a aplicação fosse desenvolvida com React e tivesse TypeScript (outro requisito obrigatório);
- As informações da página vinham de uma API também da própria empresa (nada de usar JSONPlaceholder nesse caso aqui...).
Esses eram os requisitos obrigatórios que deveria ter no teste, mas é claro que haviam outros que contariam pontos se você (eu) conseguisse fazer... alguns deles:
- Deixar a aplicação 100% responsiva e acessível;
- Manter o código simples e reutilizável;
- Não fugir do layout (tinha que estar exatamente igual);
- E claro, tempo de entrega... quanto mais rápido você conseguisse desenvolver a aplicação e entregar, melhor.
Acredito que esses requisitos sejam válidos para qualquer teste que eu e você vá fazer no futuro. Claro que podemos acrescentar mais alguns como testes unitários, quanto menor o bundle melhor, paginação, performance, e por aí vai...
3. 🏗️ Planejamento e Tecnologias utilizadas
Nesse tópico fiz o que qualquer ser humano faria: peguei papel e caneta e comecei a desenhar a estrutura do projeto.
Parecia ser um projeto bem simples, porém demandaria um certo tempo para que tudo funcionasse conforme os requisitos. Primeiro constatei o óbvio: usaria React e TypeScript.
E por se tratar de um pequeno sistema de blogs, a escolha foi usar Vite, afinal ele é leve e poderia ser pré-configurado com os itens necessários para o desenvolvimento.
A primeira etapa já estava definida: Vite > React + TypeScrit > estilização usando Tailwind (escolhi utilizar Tailwind porque pra mim é algo muito mais rápido e simples de configurar, acelera o desenvolvimento da aplicação, tem uma performance otimizada, sem contar que Tailwind é muito mais amigável com aplicações mobile, já que a responsividade é simplificada).
Agora estava na hora de pensar como seria a comunicação com o backend. Escolhi utilizar React Query. Apesar de ser uma biblioteca externa, ela é ótima, pois permite trabalhar com server state de forma bem simples. React Query já traz os estados referente ao loading, aos dados, aos erros, e tudo que for necessário bem simplificad;, e também temos a facilidade de controlar quando terá um refetch nos dados e cache. Ou seja, é uma biblioteca que tem muitos benefícios.
E como eu integraria o React Query para chamar os serviços responsáveis por trazer os dados: hooks customizados. Como eu usaria uma REST API, acredito que seria uma boa combinação.
Seguindo o planejamento, a ideia aqui também foi aplicar os conceitos de clean architecture, criando uma estrutura de pastas e arquivos onde as responsabilidades não se misturavam. Eu criaria um custom hook para cada coisa (por exemplo: usePosts para exibir os posts; useCreatePost para quando um usuário fosse criar um post, e por aí vai...). Uma pasta somente com os componentes da aplicação e outra com os componentes que poderiam ser reutilizados (por exemplo: , , etc...). Outra pasta para serviços, etc...
Como a aplicação não seria muito grande, caso necessitasse de um gerenciamento de estado um pouco mais robusto, eu utilizaria o Context API por ser uma solução nativa e assim ajudar a evitar props drilling na aplicação.
Após escrever tudo que eu precisava fazer, cheguei a essa conclusão de estrutura:
src/
├── components/ # Componentes da aplicação
│ ├── PostList.tsx
│ └── PostItem.tsx
├── hooks/ # Custom hooks para lógica de negócio
│ ├── useCreatePost.ts
│ └── usePosts.ts
├── pages/ # Páginas existentes
│ ├── dashboard/
│ │ └── index.tsx
│ └── login/
│ └── index.tsx
├── services/ # Lógica de dados/API
│ └── posts.ts
├── shared/ # Componentes reutilizáveis
│ ├── Button.tsx
│ └── TextInput.tsx
├── styles/ # Estilos globais e configuração do Tailwind CSS
│ └── index.css
├── App.tsx # Página inicial da aplicação com verificação de usuário logado
└── main.tsx # Ponto de entrada e configuração inicial do React Query
1. 🔰 Contexto
Primeiramente gostaria de dizer que esse post será longo, mas prometo que valerá bastante a pena 😊
Recentemente participei de um processo seletivo onde o desafio era desenvolver um CRUD (Create, Read, Update, Delete) utilizando React. Apesar de eu não ter avançado, decidi documentar todo o processo, desde sua concepção até os aprendizados.
Espero que essa documentação detalhada ajude outro desenvolvedor no futuro, incluindo eu mesma (pois sempre utilizo meus próprios códigos como documentação ou para fazer algo diferente). Então vamos ao processo...
2. 📋 Requisitos do desafio
O teste consistia em desenvolver um CRUD bem simples, a empresa forneceu algumas informações que precisavam ser seguidas a risca:
Esses eram os requisitos obrigatórios que deveria ter no teste, mas é claro que haviam outros que contariam pontos se você (eu) conseguisse fazer... alguns deles:
Acredito que esses requisitos sejam válidos para qualquer teste que eu e você vá fazer no futuro. Claro que podemos acrescentar mais alguns como testes unitários, quanto menor o bundle melhor, paginação, performance, e por aí vai...
3. 🏗️ Planejamento e Tecnologias utilizadas
Nesse tópico fiz o que qualquer ser humano faria: peguei papel e caneta e comecei a desenhar a estrutura do projeto.
Parecia ser um projeto bem simples, porém demandaria um certo tempo para que tudo funcionasse conforme os requisitos. Primeiro constatei o óbvio: usaria React e TypeScript.
E por se tratar de um pequeno sistema de blogs, a escolha foi usar Vite, afinal ele é leve e poderia ser pré-configurado com os itens necessários para o desenvolvimento.
A primeira etapa já estava definida: Vite > React + TypeScrit > estilização usando Tailwind (escolhi utilizar Tailwind porque pra mim é algo muito mais rápido e simples de configurar, acelera o desenvolvimento da aplicação, tem uma performance otimizada, sem contar que Tailwind é muito mais amigável com aplicações mobile, já que a responsividade é simplificada).
Agora estava na hora de pensar como seria a comunicação com o backend. Escolhi utilizar React Query. Apesar de ser uma biblioteca externa, ela é ótima, pois permite trabalhar com server state de forma bem simples. React Query já traz os estados referente ao loading, aos dados, aos erros, e tudo que for necessário bem simplificad;, e também temos a facilidade de controlar quando terá um refetch nos dados e cache. Ou seja, é uma biblioteca que tem muitos benefícios.
E como eu integraria o React Query para chamar os serviços responsáveis por trazer os dados: hooks customizados. Como eu usaria uma REST API, acredito que seria uma boa combinação.
Seguindo o planejamento, a ideia aqui também foi aplicar os conceitos de clean architecture, criando uma estrutura de pastas e arquivos onde as responsabilidades não se misturavam. Eu criaria um custom hook para cada coisa (por exemplo: usePosts para exibir os posts; useCreatePost para quando um usuário fosse criar um post, e por aí vai...). Uma pasta somente com os componentes da aplicação e outra com os componentes que poderiam ser reutilizados (por exemplo: , , etc...). Outra pasta para serviços, etc...
Como a aplicação não seria muito grande, caso necessitasse de um gerenciamento de estado um pouco mais robusto, eu utilizaria o Context API por ser uma solução nativa e assim ajudar a evitar props drilling na aplicação.
Após escrever tudo que eu precisava fazer, cheguei a essa conclusão de estrutura: