React para um projeto que já é grande e pretende crescer, Redux e Sagas?

[wilsongomes-swe]

Boa tarde galera, gostaria de uma opinião,

estou iniciando um projeto, que será grande em questão de features, será um VOD (estilo netflix de app, Video On Demand)... Comecei ele aqui, mas estou fazendo os requests direto nos componentes das páginas, por exemplo, a home carrega várias sessões e estas sessões carregam suas playlists, faço isso no useEffect(()=>{ ... }, []) da home... A tela de um canal especifico: faço o mesmo, carrego os dados no useEffect daquela Page e mando os dados nos componentes....

Não sei se este seria um padrão legal, sinto que estou sendo produtivo assim, mas daqui a pouco será toda uma equipe neste projetos, e eu serei o responsável por guiar a arquitetura e estrutura dele...

Algumas pessoas me disseram para usar arquitetura flux com redux e sagas, para assim minhas views só chamarem actions q atualize os seus states por um reducer.

O pessoal aqui está perguntando sobre a arquitetura deste projeto, não estou usando nenhuma como uso no backend, DDD ou MVC ou até as vezes MVP ou MVVM em apps... Mas no front do site, por mais que ele terá muita responsabilidade e será SPA, acho que usar apenas o MV, com a comunicação da api tanto o envio dos dados quanto as consultas direto naquele componente está sendo produtivo e não vejo algo que atrapalhe na manutenção futura...

Mas o que vocês indicam? Procuro colocar uma arquitetura mais robusta? Uso redux / flux? Ou usar apenas para os estados compartilhados como aqueles pertinentes ao usuário logado?

Sou backend também, e costumo ver como um grande erro aqueles códigos em que no meio da view a galera coloca consulta no banco + regras de negócio e etc... Mas por se tratar do front web, não estou vendo ainda a necessidade de tentar estruturar uma arquitetura mais complexa, e tenho o receio de uma arquitetura como MVP, MVC trazer apenas complexidade e não manutenabilidade e performance...

O que vcs acham? E o que vcs usam??

Se alguem puder dar essa força... abraços!

[AlbericoD]

Existe uma abordagem muito boa chamada de feature folders, eu adotei em 2 projetos e a estrutura está concisa e com possibilidades de abusar de escopo de componentes, eu encontrei algo parecido nas docs do @redux/toolkit
em alguns projetos pequenos eu já utilizei a abordagem por 'pastas de tipos - estilo rails' mas conforme a codebase do projeto vai crescendo as coisas começam a ficar muito difíceis de manter ou adicionar.

aqui tem um projeto que criei recentemente pra exemplificar o que eu acho ideal de documentação minima e a estrutura de 'feature folder', observe que não é um aplicativo web normal, mas serve como exemplo.

agora, só uma observação, utilize apenas o que você sentir necessidade, e documente pelo menos o fluxo da sua arquitetura para futuros participantes do projeto.

[eliseumds]

Eu peguei o comecinho de redux-saga e fiquei muito animado, usei em uma porrada de lugares, e me arrependo. 95% do que escrevi com sagas poderia ser refeito facilmente com hooks. Hoje utilizo redux pra guardar usuário e suas preferências, e routing, mas até isso poderia ser movido pra React.Context.

Hoje eu utilizo redux e redux-saga numa aplicação backend em tempo real, e aí sim eu vejo que faz sentido. No frontend, penso que é overkill.

O react-query pode resolver a maioria das suas necessidades em termos de data fetching. Tem suporte a paginação, optimistic updates e vem até com DevTools.

[ninetails]

@eliseumds Tem uns resources pra sharear sobre react-query?

[eliseumds]

@ninetails eu recomendo clonar o repo e brincar com os arquivos no diretório "examples". Como hooks são fáceis de extrair, você pode criar seu próprio wrapper pra evitar se repetir. No nosso caso, nós temos uma lógica especial pra injetar o "actor" da requisição e uma função pra serializar a query string de acordo com o que o nosso backend aceita. O repositório inclui exemplos de custom hooks: https://github.com/tannerlinsley/react-query/tree/master/examples/custom-hooks.

[ViniciusGularte]

Aqui na empresa temos um Saas gigante, to usando o React.Context para guardar usuário e suas preferências, informações de rotas,como o @eliseumds tinha falado ali, e tem funcionado perfeitamente, no começo do desenvolvimento deste Saas ja quis logo de cara ir colocando redux+sagas, porém vi que realmente não precisa e acabei removendo, o context e os hooks quebraram o galho e facilitaram muito.

[wilsongomes-swe]

Shos @ViniciusGularte , isso que to pensando tbm, muito obrigado..

Uma outra dúvida, vejo vocês falando que salvam as rotas no estado e tal... Mas até agora eu uso minhas rotas no arquivo de configuração, puxando pro router e diferenciando as rotas protegidas das publicas, só isso, mas sem usar estado... E ainda não vi algo q necessitasse passar elas para o estado...

Por que vcs usam por estado? E qual seria o processo usando assim?

Muito obrigado!
Abraços!

[oHervis]

Cara, se eu posso te dar uma dica realmente util para projetos que pretendem escalar, Se torne independente do framework. Deixe toda sua lógica, chamada a apsi e as regras (que deve ser mínimas) fora dos componentes. Utilize o vanilla pra isso.
Uma outra pergunta realmente importante é, você precisa mesmo de React? Seu time tem experiência com React? Será que não tem alguma outra alternativa?
E por útimo mas não menos importante, se você realmente vai usar React/Redux. Utilize com cuidado, para o Redux virar um espaguete dentro do seu projeto basta meia hora de código ruim.
Use gerenciador de estados globais para estados globais. Caso o contrário, vai do conceito de event-up, propDown.
Boa sorte ai ;)

[wilsongomes-swe]

@AlexandroWillianHervis valeu pelas dicas, e sim, estamos tentando manter a lógica em vanilla, o time ta afiado em react e optamos por ele por sentirmos um grande ganho de performance e de manutenabilidade do código usando ele frente ao padrão antigo que era html, css, js, bootstrap, jquery...

A galera ta mandado bem e entregando mais, mas nos projetos menores, agora vamos atacar o core da empresa, a aplicação que paga nossas contas kkk Por isso vindo ver a opinião de vcs antes sobre estes pontos.

Mas ocm certeza vai ser react. (Testamos outros frameworks como Vue, e foi sucesso também, mas por mercado vamos de react que conseguiremos escalar a equipe mais facil)