Executando verificação de segurança...
2

Qual o problema do Redux?

Volta e meia surge na comunidade essa discussão sobre gerenciamento de estado e, de que o Redux já está ultrapassado, de que tem muitas outras bibliotecas novas muito melhores como Zustand e Jotai(e de certa maneira é ate verdade). E sim, o Redux puro talvez esteja um pouco obsoleto, mas hoje temos o Redux-Toolkit que pra mim resolve todos os problemas que tive no passado, sendo bem simples de configurar e usar. E pelo que sei, ele ainda é o padrão do mercado.

Só não entendo esse "anti-hype" do Redux. Ele resolve o meu problema de forma excelente e performática. Já é bem maduro. Tem uma comunidade forte.

Se funciona bem e resolve todos os meus problemas, porque eu iria troca-lo?

Carregando publicação patrocinada...
6

Isso acontece muito com tecnologias no hype. Não tem nada de errado usar redux, como sempre fez. Ele pode até ter algumas funcionalidades a menos que outros, é normal, mas continua funcionando e é muito confiável. Se a tecnologia está sendo mantida e recebendo manutenção, pode usar sem se preocupar.

Outra coisa que ocorre também é que já existem milhões de cursos falando sobre redux, então é mais rentável começara falar de outras ferramentas, como o próprio Zustand. No fim, tudo funciona, não tem nada de errado em utilizar uma ferramenta um pouco mais antiga.

Ainda existem projetos utilizando Jquery, react puro, js vanilla e por aí vai. se você se sente melhor em utilizar redux, utilize redux.

1

Verdade! Esse hype em novas tecnologias rende muito dinheiro. A comunidade tech influencer pira.

Vou continuar a usar o Redux Toolkit até ele morrer.

4

Olá gabeFrank,

Acompanhei as suas ponderações sobre o Redux e o Redux Toolkit, bem como as observações dos outros colegas. Concordo que o Redux se estabeleceu como uma escolha sólida no mundo do React, e o Redux Toolkit simplificou significativamente seu uso. No entanto, é crucial considerar outros aspectos do gerenciamento de estado em aplicações web.

Gerenciar estado em aplicações web é um desafio notoriamente complexo. Nenhuma solução é perfeita para todos os cenários, o que explica a variedade de ferramentas como Zustand, Jotai, entre outras. Cada uma dessas ferramentas, incluindo o Redux, foi projetada para resolver tipos específicos de problemas de gerenciamento de estado. Por exemplo, enquanto o Redux é excelente para gerenciar estados globais complexos, ele pode ser excessivo para situações mais simples, onde soluções como Context API do React ou mesmo um simples gerenciamento de estado local podem ser mais adequadas.

Para estados globais uma abordagem muitas vezes esquecida pelos desenvolvedores sem experiência é o uso da URL ou do próprio documento como um estado global. Utilizar a URL como parte do estado global de uma aplicação permite manter a sincronização com o histórico de navegação do navegador e facilita o compartilhamento de estados específicos da aplicação através de links.

Além disso, o próprio documento pode ser uma fonte de estado global. Isso inclui o uso de atributos de dados, armazenamento local ou de sessão e até cookies. Esses métodos podem ser usados para manter informações de estado que precisam ser persistidas durante a sessão.

Outro ponto que ainda não foi mencionado, mas que merece atenção, é o padrão event bus. Esse padrão oferece uma abordagem alternativa para o gerenciamento de estado, permitindo que diferentes componentes de uma aplicação comuniquem entre si de maneira desacoplada, através de eventos. Embora possa ser menos conhecido, ele fornece uma maneira flexível de gerenciar interações complexas em grandes aplicações e é literalmente o que o Angular chama de Signals.

Finalmente, o Padrão Observer, como descrito no clássico livro "Design Patterns" dos Gang of Four, é um padrão fundamental na engenharia de software. Ele permite que objetos (ou componentes neste caso) observem e reajam a eventos ou mudanças de estado em outros componentes. Este padrão é a base de muitas soluções modernas de gerenciamento de estado e fluxo de dados, incluindo a supracitada Signals.

Em conclusão, como você já percebeu, é importante sempre ter um pé atrás com as tecnologias da moda, mas é preciso sim entender profundamente os problemas que elas resolvem. Assim, com estudo e conhecimento, você pode tomar a melhor decisão para o seu projeto. Por favor, não use o Redux para tudo e sempre. Existem muitas ferramentas e abordagens disponíveis, e cada uma tem seu lugar dependendo das necessidades específicas do seu projeto.

2

Muito obrigado pelo seu excelente comentário! Meditei bastante nele e apreciei tamanho conhecimento.

Utilizo o Redux pois sempre cumpriu bem o seu papel para aplicações mais complexas. Já dei uma olhada nas implementações do Zustand e não vi tanta vantagem. É simples, rápido e minimalista, mas em relação ao Redux não vi nada que justificasse trocar. Para algo mais simples nem vejo lógica em usar gerenciamento de estado.

Sobre as URLs: acho excelente e simples. Já usei algumas vezes. Isso me remete ao princípio KISS(keep it simple stupid!).

Não conhecia esse padrão Event Bus. Simplesmente sensacional! Tenho o livro Padrões de Projeto e tem muita, mas muita coisa valiosa!

De fato, eu já cogitei usar cookies e localStorage, mas sempre tive uma ideia de que cookies são pra dados mais sensíveis e localStorage para dados de configuração mais genéricos, pois eles não mudam com tanta frequência. Vou dar uma estudada.

Mais uma vez, muito obrigado!

1

Aqui no trabalho, a galera respeita muito o Redux, e pelo menos a maioria dos devs sabe diferenciar que o tech influencer está querendo fazer hype para montar um negócio e largar a comunidade depois que fizer grana.

1

Pois é. Podemos ver ao longo dos anos o prejuízo que algumas empresas e startups tiveram ao trocar sua stack pronta e estável por alguma tecnologia da moda. A época do MongoDB "bala de prata" foi o maior exemplo, na minha opinião.

2

Acho que o Redux legado não tem condições de ser a primeira opção no cenário atual, imagino que nem considerado seja, muito boilerplate pra poder configurar. Você está certo, quando falamos de Redux Toolkit a coisa muda, é bem mais simples e direto ao ponto.

Imagino que muito dessa resistência ao Redux (que também transborda no Toolkit) vem do Redux legado, outras soluções foram criadas como alternativas e o mesmo acabou perdendo espaço, mesmo tendo evoluido com o Toolkit.

No fim, na minha opinião, se você escolher o Redux Toolkit está tudo bem, eu já usei e confesso que achei tranquilo e simples, é questão de gosto, outros vão peferir nem ver a cara do Redux e ir de Zustando ou outro. Como mencionei, imagino que não seja usado por conta da resistência criada sobre o Redux, mas, sim, é uma boa opção.

1

Você está certo! O Redux Toolkit pegou a fama ruim do Redux antigo, infelizmente...

Tanto que a maioria dos exemplos que vejo na internet é do antigo, pouco se vê o Toolkit. Sem contar que a documentação dele é uma beleza.

1

Pois é, usei o Toolkit em alguns projetos e me atendeu super bem, sendo pouco verboso e fácil de Implementar! Eu lembro na primeira vez q fui usar, q foi mt fácil de configurar pra uma primeira vez. Mas hj essa galera nova não se atenta pra documentação, por isso vemos hj, principalmente no ecossistema do Javascript, tanta lib mal documentada (isso quando tem uma documentação q faz jus ao nome).

Agr o antigo é uma tristeza.. kkk mt verboso e ruim de configurar

2

Sua pergunta é inteligente pois já traz a resposta: se funciona bem, não precisa trocar.
Porém atente-se! Caso a biblioteca esteja defasada ou insegura, vale a pena observar outras opções para uma migração futura.

1

Exatamente. Sempre estou atento no ciclo de vida dos módulos, assim como quem está mantendo, se é alguem ou um grupo sério. Acredito muito que o Redux tem mantenedores compremetidos. Fico com um pé atrás sobre módulos novos e hypados pois não sei quem de fato está por trás. Nada impede dele ser abandonado do nada.

2

Isso é meio que normal, especialmente no ramo de tecnologia, mais especialmente ainda em tecnologias javscript, são muitas pessoas querendo ser diferente ao mesmo tempo, simplesmeste não da hahahahha

1
1

Atente-se sempre a afirmações como "muito melhores", isso sempre, eu digo com toda certeza, sempre é relativo. Sempre que alguém afirmar isso, pergunte a ela, de que ponto de vista é melhor?

O Redux é um ótimo gerenciador de estados, mas ele é bastante verboso, você precisa implementar "bastante coisa" em uma estrutura rígida para começar a usar, isso obviamente te dá mais trabalho para dar o primeiro start na utilização, por outro lado, gerenciadores como o Zustand são muito mais simples de se escrever, inclusive só para ter noção, no Zustand você nem chega a declarar providers no seu layout.tsx.. Então de forma grotesca, um você gasta mais recurso para implementar e necessita ter um conhecimento mais profundo, além de que o Redux te força a seguir uma estrutura organizada desde o princípio, enquanto outro te oferece um desenvolvimento mais rápido, mas coloca você no comando total para organizar e garantir implementações que possam receber manutenção sem grandes dores de cabeça.

Acredito que essa maior "facilidade" do Zustand e outras ferramentas faz com que as pessoas chamem o Redux de ultrapassado.. mas é importante lembrar, a utilização do Redux em termos de sintaxe, é tão próxima da estrutura do Context Api quanto qualquer outra.

0