Redux em forms vale a pena?

[victorsilent]

Então, usar ou não redux sempre gera aquela conversa de sempre... Usar quando componentes compartilharem do estado, ter time-travel e etc.
Eu particularmente não sou fã de usar ele em forms e atualmente estou construindo portfólio, então estou usando todas as "estrelinhas" do mundo react e uma delas é o redux-form, dai tive a dúvida, vi que a cada keystroke ele vai lá e da um updatezim no meu state, no caso do meu app que é bem simples, tudo show, mas levando a coisa um pouco pra frente acredito que isso não deva ficar tranquilo quanto a questão da performance, estou certo?
Como vocês lidam com o redux em forms? Usam alguma lib? Passam pra um componente maior gerenciar?

[diessica]

não acho que "depende" é uma resposta interessante, mas infelizmente é a resposta genérica perfeita para "ferramenta X vale a pena?".

primeiro, existem as vantagens originadas pelo estado do formulário estar na store, e as vantagens da abstração do redux-form em si. vou misturar tudo e lá vai:

o redux-form é interessante para formulários maiores e mais complexos em que é necessário maior controle, consistência e até persistência (facilmente plugável com bibliotecas como redux-persist, por exemplo, já que ele sempre conta com o estado da store).

curto a abstração dele para questões como validação (seja síncrona ou assíncrona), tanto a nível de campo quanto a nível de formulário (os erros são bastante claros e ficam também na store). é possível também manipular o formulário a partir de qualquer lugar da aplicação (afinal, ele fica no reducer e é só disparar uma action!), sem que você crie seu próprio reducer e actions. é bastante flexível, e qualquer coisa pode servir como um Field – um input seu customizado, 3rd party ou um input HTML normal.

o preço é uma abstração, né. mas você ganha uma estrutura consistente e sólida para construir formulários, seja 1 ou, principalmente, vários. você vai ter todos os formulários da sua aplicação consistentemente estruturados. recentemente usei ele para fazer um wizard form de 3 passos, cada passo com um formulário com campos e validações diferentes (e, que, no final, se tornam um só – então na real é um formulário gigante, só que separado no front-end), e está rodando muito bem.

um ponto importante que você fez:

mas levando a coisa um pouco pra frente acredito que isso não deva ficar tranquilo quanto a questão da performance, estou certo?

você nunca deve ficar tranquilo quanto à performance, mas a boa notícia é que o redux-form é bem otimizado (veja redux-form/redux-form#529 e redux-form/redux-form#1405). se você perceber algum bottleneck depois que construir seu formulário, você pode otimizar ainda mais também.

considerando que você já se convenceu que quer o estado do seu formulário na store, que ele é não-trivial o suficiente para viver lá, eu daria uma chance para o redux-form, principalmente em vez de fazer a sua própria solução. ele já sofreu bastante para chegar no formato que chegou, e está bem maduro e otimizado :)

btw, outro interessante é o formik: https://github.com/jaredpalmer/formik

[fakenickels]

Eu julgo estados de form ser algo efêmero demais pra ficar em algo como redux, atualmente prefiro uma solução de estado local mesmo como o Formik que a @diessica falou em ReactJs ou ReForm em ReasonReact

[felisio]

@victorsilent , deixo aqui um post para ajudar na sua analise espero que te ajude:
Redux Form is dead!
Já usei e no meu caso não me atendeu.... mais cada caso é um caso...

[diessica]

tem post de "X is dead" pra tudo, e esse aí é bem tendencioso, até usa a citação do Dan Abramov de forma distorcida para sustentar o argumento. o Dan não escreveu aquilo em pedra (ele, inclusive, nem curte fazer isso); mas para incentivar que pensemos onde armazenar o estado de formulários.

como eu disse antes, depende da efemeridade do estado. para mim, o estado de um wizard form com passos (que deve persistir até o final do formulário, além de, como eu disse, poder ser persistido através de libraries como redux-persist), cujos inputs podem implicar em mudanças na UI (ou seja, componentes externos do formulário também reage às mudanças do formulário) ou podem ser alterados externamente, não é efêmero como o estado de um formulário para se inscrever numa newsletter. não é efêmero quanto um formulário de contato. é uma informação que a aplicação precisa e que se beneficia.

quanto à atividade do projeto, é sim algo a se pensar. também é importante considerar que o autor do projeto, Erik, recentemente começou o final-form, mas não é como se o redux-form não fosse maduro e não fosse uma solução legal. ainda é mantido e a documentação é ótima (só ver a atividade, ou então tentar desenvolver algo com ele – as docs cobrem tudo).

[victorsilent]

Eu continuei com o uso do redux-form e apliquei alguns testes, adicionei mais campos no estado da aplicação e criei forms maiores (70+ campos) e ele não deu nenhum sinal de problema. Depois vou testar essa questão do re-render, não lembrei e acabou passando batido. De todo modo, como todos disseram e a @diessica pontuou bem, manter o form no redux seria questão de analise da complexidade do form em termos de implicações em outros locais da aplicação, o que não é o caso do meu form, então apesar de usar o redux-form eu irei dar uma olhada nas outras soluções, ja que a maioria dos forms são triviais e não irão exigir o uso do redux.
Muitíssimo obrigado a todos, deram uma luz legal pro meu problema :)

[diessica]

me vi voltando nessa discussão novamente após comentar aqui, então resolvi traduzir para inglês e introduzir mais alguns pontos nas minhas respostas acima. para quem quiser estiver interessado no tópico:

React and Form Management: Is Redux Form Worth It? (inglês)