Trabalho avaliado, obrigado pela entrega!

[lucasferreira]

Jovens,

Gostei bastante de vário aspectos do trabalho de vocês, desde a unidade visual até a "grande e organizada estrutura base" que vocês levantaram para rodar esse projetinho.

Acho que têm muita tecnologia boa envolvida aqui, mas vou deixar algumas sugestões:

• Olhar as issues que deixei em aberto;
• Usar mais os recursos de renderização de servidor do Next e menos fetch/axios no front-end;
• Reduzir o uso de Redux / Saga uma vez que os dados estarão mais no back do que no front (essa é a ideia do Next);
• Implementar uma solução de formulário mais robusta como Formik ou react-hooks-form.

Fora os pontos acima o resto ta bem dentro do escopo e requisitos, obrigado novamente pela presença em sala de aula e espero ver todos vocês no futuro ;)

[gustavo-valsechi]

Bom dia professor, Poderia me explicar melhor essa parte: Reduzir o uso de Redux / Saga uma vez que os dados estarão mais no back do que no front (essa é a ideia do Next);Att, Gustavo Valsechi Em 4 de jul. de 2023 22:56, Lucas Ferreira @.***> escreveu: Jovens, Gostei bastante de vário aspectos do trabalho de vocês, desde a unidade visual até a "grande e organizada estrutura base" que vocês levantaram para rodar esse projetinho. Acho que têm muita tecnologia boa envolvida aqui, mas vou deixar algumas sugestões: Olhar as issues que deixei em aberto;Usar mais os recursos de renderização de servidor do Next e menos fetch/axios no front-end;Reduzir o uso de Redux / Saga uma vez que os dados estarão mais no back do que no front (essa é a ideia do Next);Implementar uma solução de formulário mais robusta como Formik ou react-hooks-form. Fora os pontos acima o resto ta bem dentro do escopo e requisitos, obrigado novamente pela presença em sala de aula e espero ver todos vocês no futuro ;)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[lucasferreira]

Claro jovem,

Como tu usa Redux Saga dentro das "sagas" / actions tu acaba fazendo muitos fetchs direto no front, consumo de API clássico (no teu caso com axios). Isso não é errado e funcionaria muito bem em um projeto com Vite ou CRA por exemplo.

No caso do Next, que é um framework React, uma das vantagens que nós temos é que o mesmo roda "desde o servidor" (back) até chegar ao front do usuário, nesse caso o Next renderiza todo o nosso "React" (componentes) primeiro no servidor e depois uma segunda vez de novo no front-end do usuário (chamamos isso de hydratation, essa segunda renderizada).

Ai o que ocorre hoje na tua aplicação, já que o consumo de APIs só roda no front, o Next renderiza a primeira vez e gera um monte de componentes meio que "vazios" sem conteúdo, pq o conteúdo não está programado para ser consumido da API via servidor, ai continuamos recebendo uma primeira carga de renderização do servidor "meio que vazia" para somente após o front rodar abastecer a tela com os dados da API.

Como eu disse isso é "de boa" nos casos de Vite/CRA pois não temos servidor envolvido ali, só front. Mas no caso do Next é bem interessante que usemos recursos como getStaticProps e getStaticPaths para que o Next faça o consumo de APIs também no lado do servidor para entregar um ao front uma aplicação/site praticamente já abastecido de dados e o usuário não ter que esperar pelo front fazer muito "trabalho" além das poucas interações de UI (tipo menus, troca de tema e outros widgets).

Aqui neste exemplo que fiz em sala de aula da para ver bem isso: https://codesandbox.io/p/github/lucasferreira/front-end-demo-next/main?file=/pages/produtos/[id].js:36,23-36,37

No exemplo acima, temos uma página que renderiza produtos que vem de um API, o ID do produto é obtido pela URL e na função getStaticProps é feito o consumo de API (sem necessidade de usar redux ou saga, é só uma leitura simples) depois no componente em si Produto o dado que da API já está ali para só ser usado, desde o servidor e já chega prontinho e abastecido no front, sem necessidade de usar o AXIOS mais uma vez.

Óbvio isso funciona bem (no caso do NEXT) em 95% dos casos, ainda vão ter casos tipo análise de dados em tempo real que tu vais precisar fazer fetch no front de tempos em tempos ou usar um WEBSOCKET para receber esses dados pós entrega do back.

Beleza meu?

[gustavo-valsechi]

Entendii, valeuu 👊🏽

Obter o Outlook para Androidhttps://aka.ms/AAb9ysg

---

From: Lucas Ferreira @.> Sent: Wednesday, July 5, 2023 8:33:56 AM To: CODEX-10/calendle @.> Cc: Gustavo | Valsechi @.>; Comment @.> Subject: Re: [CODEX-10/calendle] Trabalho avaliado, obrigado pela entrega! (Issue #3)

Claro jovem,

Como tu usa Redux Saga dentro das "sagas" / actions tu acaba fazendo muitos fetchs direto no front, consumo de API clássico (no teu caso com axios). Isso não é errado e funcionaria muito bem em um projeto com Vite ou CRA por exemplo.

No caso do Next, que é um framework React, uma das vantagens que nós temos é que o mesmo roda "desde o servidor" (back) até chegar ao front do usuário, nesse caso o Next renderiza todo o nosso "React" (componentes) primeiro no servidor e depois uma segunda vez de novo no front-end do usuário (chamamos isso de hydratation, essa segunda renderizada).

Ai o que ocorre hoje na tua aplicação, já que o consumo de APIs só roda no front, o Next renderiza a primeira vez e gera um monte de componentes meio que "vazios" sem conteúdo, pq o conteúdo não está programado para ser consumido da API via servidor, ai continuamos recebendo uma primeira carga de renderização do servidor "meio que vazia" para somente após o front rodar abastecer a tela com os dados da API.

Como eu disse isso é "de boa" nos casos de Vite/CRA pois não temos servidor envolvido ali, só front. Mas no caso do Next é bem interessante que usemos recursos como getStaticProps e getStaticPaths para que o Next faça o consumo de APIs também no lado do servidor para entregar um ao front uma aplicação/site praticamente já abastecido de dados e o usuário não ter que esperar pelo front fazer muito "trabalho" além das poucas interações de UI (tipo menus, troca de tema e outros widgets).

Aqui neste exemplo que fiz em sala de aula da para ver bem isso: https://codesandbox.io/p/github/lucasferreira/front-end-demo-next/main?file=/pages/produtos/[id].js:36,23-36,37https://codesandbox.io/p/github/lucasferreira/front-end-demo-next/main?file=/pages/produtos/%5Bid%5D.js:36,23-36,37

No exemplo acima, temos uma página que renderiza produtos que vem de um API, o ID do produto é obtido pela URL e na função getStaticProps é feito o consumo de API (sem necessidade de usar redux ou saga, é só uma leitura simples) depois no componente em si Produto o dado que da API já está ali para só ser usado, desde o servidor e já chega prontinho e abastecido no front, sem necessidade de usar o AXIOS mais uma vez.

Óbvio isso funciona bem (no caso do NEXT) em 95% dos casos, ainda vão ter casos tipo análise de dados em tempo real que tu vais precisar fazer fetch no front de tempos em tempos ou usar um WEBSOCKET para receber esses dados pós entrega do back.

Beleza meu?

— Reply to this email directly, view it on GitHubhttps://github.com/CODEX-10/calendle/issues/3#issuecomment-1621576437, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUKQTDTM3LR7FUCTUWUCVGDXOVGKJANCNFSM6AAAAAAZ6JTTOE. You are receiving this because you commented.Message ID: @.***>