A mais de 10 anos tenho conta no TH-cam ; se fiz 6 comentarios ao longo desse tempo foi muito rsrs! . O conteúdo tá muito bom e estou seguindo a playliste.
Duvida, se tudo oque esta no app renderiza no lado do servidor como o navegador carrega o conteudo enviado pelo servidor? Ele usa javascript para isso? Porque como o navegador recebe oque vem do servidor sem usar javascript para isso? Por que o componente client precisa de javascript e o componente do servidor não? Gostaria de entender melhor
Muito bom o conteúdo, amigo, me esclareceu algumas dúvidas. Se puder me tirar nova dúvida, por gentileza. Esse tipo de composição de componentes para segregar o que é cliente e server muda um pouco o jogo em relação a padrão de projeto no react, eu por exemplo costumava utilizar o padrão em que cada tela tem um arquivo index que tratava apenas da lógica dos estados e apenas passava como props o resultado dos dados para que um componente stateless de View exibir. Esse padrão alinhado com uma segregação por módulos deixava tudo muito bem organizado e escalável. Nesse novo modo de compor componentes, isso muda, entra em conflito com o padrão descrito por mim, porque exige que componentes contenham seu próprios estados. Você tem alguma sugestão de qual o padrão de projeto ideal e escalável para esse modo de desenvolver em react?
Obrigado pelo comentário. O próprio next te oferece um padrão que é colocar o underscore antes do nome da pasta, assim essa pasta não será renderizada como uma URL. Você pode organizar seus componentes dessa forma, por exemplo, você tem a pasta "sobre" e dentro dela tem uma pasta chamada "_componentes" onde você pode armazenar seus componentes tanto server, quanto client, e nesse caso essa pasta componentes não irá se tornar uma URL na aplicação
Essa é a parte mais confusa que estou achando do Next 14 e esperava encontrar a explicação nesse video. E se fosse o contrário? Um componente Server dentro de uma página Client?
Ele vai funcionar, mas não é recomendado que utilize páginas (page.tsx) como componentes de cliente. Caso você crie um client component e dentro chame um server component irá funcionar normalmente. Cada componente é independente e o next.js sabe renderizar de acordo. Dois pontos principais de atenção: 1) Você não pode passar server components como "children" de um client component. 2) Você não pode utilizar recursos de cliente em um server component e não pode utilizar recursos de servidor em um client component.
Muito obrigado pelo retorno @@codegusoficial ! O pior que depois de horas consegui solucionar chamando um server component pelo children condicional de um client (Precisava ser cliente porque a condição é pathname). O componente precisa ser server porque preciso de um Session em tempo real. 'use client' import { usePathname } from 'next/navigation' import SignOut from "./SignOut"; import PathName from "./PathName"; export default function NavBar({children}) { return (
{usePathname() === '/user' ? (
) : ( children )}
); } Falar que entendi essa bagunça... sei lá. Mas funcionou, kkkkkk. No final, lá no template, esse children vai chamar o tal server component dentro do navbar. Segui esse tuto aqui: medium.com/@issam.ahw/demystifying-next-js-server-components-and-client-components-1b15ae405260
Muito top! Uma dúvida: seria performático processar a página no lado server com node mas buscando os dados do banco exclusivamente através de API pelo client? Pergunto isso pq tenho uma aplicação web api e estava começando a fazer a SPA em React quando me deparei com a questão de SEO. Aí estou estudando um pouco de Next, mas tentando manter a ideia de um client consumidor das API sem reconstruir o backend. Valeu
Fala Arthur, é mais performatico sim pq o Next já faz um pré render do bundle no lado do server, mas tem um ponto que você pode ver se faz sentido também: não é necessário reconstruir as APIs, você pode chamar as APIs que já tem do lado do servidor, não precisam ser todas caso nao consiga, mas dependendo de como é o seu projeto uma parte delas já da, ai vc faz um app híbrido com server e client requests.
Acredito que muitas já estejam, a que trabalho inclusive utiliza, mas por se tratar de uma tecnologia nova pode ser complicado para empresas que já tem outros sistemas montados fazer essa migração.
Eai, acham que essas mudanças vem pra melhorar ou piorar o desenvolvimento web? Comenta ai!!
A mais de 10 anos tenho conta no TH-cam ; se fiz 6 comentarios ao longo desse tempo foi muito rsrs! . O conteúdo tá muito bom e estou seguindo a playliste.
Que honra, gratidão!
Sua didáctica é top Gus, me esclareceu varias duvidas, uma série ensinando next 14, ou um projeto do zero ao deploy seria fantástico .
Valeu demais! Já temos aqui com nextjs 13, porém em breve mais projetos virão com nextjs 14
Parabéns pelo conteúdo.
Parabéns pelo seu conteúdo.
Conteúdo excelente!
Muito bom !
Didática muito boa !
otimo tutorial
Top!!!
Obrigado
show
Duvida, se tudo oque esta no app renderiza no lado do servidor como o navegador carrega o conteudo enviado pelo servidor? Ele usa javascript para isso? Porque como o navegador recebe oque vem do servidor sem usar javascript para isso? Por que o componente client precisa de javascript e o componente do servidor não? Gostaria de entender melhor
Sim, toda a parte de cliente quanto de servidor é com JavaScript, então o navegador recebe tudo via JavaScript
Você teria algum curso sobre o novo next?
Nesse momento apenas o conteúdo aqui no meu canal, mas já tenho pensado em criar algum conteúdo mais focado.
@@codegusoficial seria muito bom mesmo to começando a estudar e to meio perdido kkkkk
Muito bom o conteúdo, amigo, me esclareceu algumas dúvidas. Se puder me tirar nova dúvida, por gentileza. Esse tipo de composição de componentes para segregar o que é cliente e server muda um pouco o jogo em relação a padrão de projeto no react, eu por exemplo costumava utilizar o padrão em que cada tela tem um arquivo index que tratava apenas da lógica dos estados e apenas passava como props o resultado dos dados para que um componente stateless de View exibir. Esse padrão alinhado com uma segregação por módulos deixava tudo muito bem organizado e escalável. Nesse novo modo de compor componentes, isso muda, entra em conflito com o padrão descrito por mim, porque exige que componentes contenham seu próprios estados. Você tem alguma sugestão de qual o padrão de projeto ideal e escalável para esse modo de desenvolver em react?
Obrigado pelo comentário. O próprio next te oferece um padrão que é colocar o underscore antes do nome da pasta, assim essa pasta não será renderizada como uma URL. Você pode organizar seus componentes dessa forma, por exemplo, você tem a pasta "sobre" e dentro dela tem uma pasta chamada "_componentes" onde você pode armazenar seus componentes tanto server, quanto client, e nesse caso essa pasta componentes não irá se tornar uma URL na aplicação
Essa é a parte mais confusa que estou achando do Next 14 e esperava encontrar a explicação nesse video. E se fosse o contrário? Um componente Server dentro de uma página Client?
Ele vai funcionar, mas não é recomendado que utilize páginas (page.tsx) como componentes de cliente. Caso você crie um client component e dentro chame um server component irá funcionar normalmente. Cada componente é independente e o next.js sabe renderizar de acordo. Dois pontos principais de atenção: 1) Você não pode passar server components como "children" de um client component. 2) Você não pode utilizar recursos de cliente em um server component e não pode utilizar recursos de servidor em um client component.
Muito obrigado pelo retorno @@codegusoficial ! O pior que depois de horas consegui solucionar chamando um server component pelo children condicional de um client (Precisava ser cliente porque a condição é pathname). O componente precisa ser server porque preciso de um Session em tempo real.
'use client'
import { usePathname } from 'next/navigation'
import SignOut from "./SignOut";
import PathName from "./PathName";
export default function NavBar({children}) {
return (
{usePathname() === '/user' ? (
) : (
children
)}
);
}
Falar que entendi essa bagunça... sei lá. Mas funcionou, kkkkkk. No final, lá no template, esse children vai chamar o tal server component dentro do navbar.
Segui esse tuto aqui: medium.com/@issam.ahw/demystifying-next-js-server-components-and-client-components-1b15ae405260
Muito top! Uma dúvida: seria performático processar a página no lado server com node mas buscando os dados do banco exclusivamente através de API pelo client? Pergunto isso pq tenho uma aplicação web api e estava começando a fazer a SPA em React quando me deparei com a questão de SEO. Aí estou estudando um pouco de Next, mas tentando manter a ideia de um client consumidor das API sem reconstruir o backend. Valeu
Fala Arthur, é mais performatico sim pq o Next já faz um pré render do bundle no lado do server, mas tem um ponto que você pode ver se faz sentido também: não é necessário reconstruir as APIs, você pode chamar as APIs que já tem do lado do servidor, não precisam ser todas caso nao consiga, mas dependendo de como é o seu projeto uma parte delas já da, ai vc faz um app híbrido com server e client requests.
@@codegusoficial Massa. Valeu!
por que as empresas não estão adotando o tailwind css?
Acredito que muitas já estejam, a que trabalho inclusive utiliza, mas por se tratar de uma tecnologia nova pode ser complicado para empresas que já tem outros sistemas montados fazer essa migração.
olá, não encontrei o link para o projeto base?
Adicionei na descrição.