𝗡ã𝗼 𝗖𝗼𝗻𝗳𝘂𝗻𝗱𝗮 𝗙𝗼𝗿𝗺𝗮𝘁𝗼 𝗱𝗲 𝗗𝗮𝗱𝗼𝘀 𝗰𝗼𝗺 𝗙𝗼𝗿𝗺𝗮𝘁𝗼 𝗱𝗲 𝗘𝘀𝘁𝗮𝗱𝗼
Ao construir um formulário React, você costuma agrupar tudo em um único e grande objeto de estado.
Você vê uma seção de Endereço na sua UI. Você cria um objeto de endereço no seu estado. Parece organizado. Parece limpo.
Isso é uma armadilha.
O problema não é o React. O problema é o formato do seu estado.
Formulários não são dados estáticos. Eles são sistemas interativos. Os usuários não atualizam formulários seção por seção. Eles os atualizam campo por campo.
Por que o estado aninhado prejudica seu projeto:
- As atualizações tornam-se pesadas. Para alterar o nome de uma cidade, você deve recriar a cidade, o endereço e o objeto de formulário de nível superior para manter a imutabilidade.
- A complexidade vaza. À medida que o formulário cresce, sua lógica de validação e renderização torna-se mais difícil de gerenciar.
- O número de re-renders aumenta. Alterar um valor aninhado cria novas referências de objeto. Isso pode disparar atualizações desnecessárias em toda a sua árvore de componentes.
- A carga cognitiva aumenta. Você para de pensar no usuário e começa a pensar em caminhos de objetos.
Formulários pequenos são tolerantes. Formulários de produtos não são.
Um formulário de produção precisa de validação, salvamento automático e lógica condicional. Se você construir isso sobre um objeto profundamente aninhado, cada nova funcionalidade parecerá custosa.
A solução é projetar o estado com base em como os dados mudam, não em como eles parecem.
Um formato de estado mais plano oferece estes benefícios:
- Atualizações mais rápidas. Você mexe em menos código para alterar um único valor.
- Depuração mais fácil. As atualizações permanecem locais e previsíveis.
- Melhores limites de componentes. Você pode passar pequenos pedaços de dados em vez de objetos enormes.
Não achate tudo cegamente. Se os dados raramente mudam e sempre se movem juntos, o aninhamento está correto. Mas não aninhe as partes do seu formulário que mudam constantemente.
Faça a si mesmo estas perguntas antes de codificar:
- Quais campos mudam com mais frequência?
- Quais seções precisam de validação independente?
- Quais atualizações devem permanecer isoladas do resto da UI?
Se atualizar um campo parecer mais difícil do que a própria alteração, a estrutura do seu estado é o problema.
Pare de modelar seu estado com base na sua UI. Comece a modelá-lo com base no comportamento do seu usuário.