Server Components Done Right! (New React Feature)

Server components are officially in the React API documentation. This means that Diego has already started experimenting with the new architecture.
If you've come across other content comparing server components to PHP, Ruby, or other ideas, you should know that you won't find any of that here.
Today, the video is packed with techniques to show you how to send less JavaScript to the client side, all within a Next.js project.
So, without further ado, let's start coding.
Follow Rocketseat on social media:
Twitter: @rocketseat
Facebook: @rocketseat
Instagram: @rocketseat

[@tiomikadev]

O atual estado do React me fez experimentar outras ferramentas, e o Svelte tem sido muito mais prazeroso de trabalhar. O fato de o React ter colocado NextJS e Remix como maneiras recomendadas na documentação fez com que um monte de aluno meu se perdesse em frameworks extremamente complexas, se comparadas com o que era o React antigamente. Eu to sentindo que o React tá criando dificuldade pra vender facilidade. Meu receio é que a ferramenta vire um Angular, super pesada e difícil de aprender.

[@dieegosf]

Pode ser! Acho que não devemos fechar os olhos pra outras ferramentas, mas é aquela, nenhuma ferramenta é "famosa" simplesmente pelas vantagens técnicas e as empresas não escolhem olhando só pra isso, então pra estudos pessoais pensando no futuro até podemos ir estudando alternativas (como tenho feito também com Astro e Solid), mas olhando pra mercado ainda é difícil mirar em algo diferente da triade de React, Vue e Angular.

[@samuelfalci]

Cara, acho o React infinitamente mais difícil de entender e aprender do que o Angular e o Vue, mesmo com a chegada do NextJs. Mas deixando o gosto pessoal de lado, essa sensação é um efeito colateral do que estamos vivendo hoje, todo mundo quer o fácil e o imediato, as features são sensacionais, mas os DEVs são rasos e indispostos a se aprofundar um pouquinho a mais pra se beneficiar. É triste.

[@thallesgalv.]

Bem maneiro! Seria legal ver um vídeo com Astro mostrando também abordagem de island. Acho que com ele, temos ainda menos envio de js pro client no load inicial, coisa que o next tá buscando com a nova app folder

[@PhillipLippi]

Bacana, essa versão do Next.js te força a componentizar para poder separar o que é server e client components.

[@ivambergsilva591]

Assistir vídeos do Diegão é sempre um evento. O cara não é foda normal!

[@MarceloPlaza]

Muito bom este vídeo. Explicações claras e esclarecedoras.

[@joaojbs199]

Estava ansioso por esse vídeo HEHEH

[@principe.borodin]

RocketSeat sendo RocketSeat, conteudo top, sempre na frente. Seria muito interessante abordar a concurrent API. Que tal?

[@DanielOliveira-mb1gc]

Que aula ! ♥

[@marconisoares2186]

Vivi pra ver o front ficar mais complexo que o back.

[@DanielBergholz]

Kkkkkkkkkk é muito overengineering no frontend pelo amor de deus

[@mauriciom8539]

Mas assim kkkkkK, front é bem complexo na real, deixar componentes reutilizáveis e tipados, organizar formulários em steps por exemplo pode ficar bem complexo

[@mauriciom8539]

Front é estética, gerenciamento de estado, usabilidade e várias outras coisas. É bem comum ter mais código que backend

[@marconisoares2186]

@@mauriciom8539 programar (de verdade) é uma atividade complexa. O problema com o front é que além de ser uma tarefa complexa, os devs ainda vão fazendo over engineering e complicando ainda mais. Hoje, por exemplo, eu não acho que começar pelo front por ser "mais fácil" faça sentido. E quando eu comecei a estudar 2 anos atrás esse conselho de começar pelo front fazia sentido.

[@vitvitvitvitvitvitvitvit]

@@marconisoares2186 Front acaba sendo mais fácil por ser visual para quem tá iniciando. Fazer um HTML simples, onde o botão faz aparecer um alert é simples de fazer, além de não precisar configurar nada na maquina. No backend tu precisa baixar o interpretador e dar permissão de execução a ele, o que é simples, mas já é complicado para alguém que tá começando e não tem noção alguma de desenvolvimento. Além de que é abstrato o conceito de API inicialmente, fica mais fácil você fazer um HTML e ver que, para ter registro de formulários por exemplo, vai ter que ter um backend com conexão a um DB

[@wesleytuck241]

Cara, qeu otima explicação. Eu estava com preconceito com relação a essa moda do Nextjs e seus server components. É realmente interessante ver como os dois podem se completar.

[@leandroslopes2395]

Muito boa a explicação!!!

[@LordGhapa]

cara sou dev junior é emocionante finalmente consegui entender alguma coisas que esta sendo explicada separa em component context api reactNode pra children 😀

[@FilipeMoraes87]

Comparar server components com PHP é a mesma coisa de comparar um avião com carro só porque ambos tem pneus. Programo com PHP desde 2002 e ainda utilizo em alguns casos, a proposta do server components é muito diferente, um não vai substituir o outro e vamos continuar a utilizar ambos em contextos diferentes.

[@pthiago_s5075]

Ativa a extensão auto rename tag ae, Diegão. Outra dica: renomeia variáveis e funções usando F2 (vai renomear automaticamente em todos os arquivos)

[@henriqueomena7686]

O F12 uso a muito tempo , produtividade la encima :D

[@user-to4or3rq8l]

Eu imagino que ele deva desativar quase todas as extensões mágicas pra ficar mais explícito o passo a passo pra devs mais iniciantes. No meu time, quando preciso mostrar exemplo de algo pra um dev junior, faço a mesma coisa.

[@thawandotdev]

A extensão não é mais necessária, agora se você der um F2 em um elemento no JSX usando o VSCode ele já renomeia

[@eduardooliveira5257]

Eu achei incrível esse novo conceito do Nextjs

[@Viniciusgnux]

Brabissimo, react veio para dominar e deixar nossa pagina com mais performance 🙌🏽 graças ao tio Zuckerberg.

[@diego_maia]

Excelente!!!

[@pthiago_s5075]

Se for trazer intercepting routes com parallel routes n esquece de usar no máximo a versão 13.4.7 do next, única q funciona kkkk

[@DjEdu28]

vlw Diegão!

[@leonardopn]

A ideia dos server components atualmente funciona muito bem com a context API. Como o Diego mostrou, integrar componentes server com components client fica extremamente fácil e a passagem de props mais ainda se vc usa a context API, porém, pra quem precisar usar por exemplo libs como Redux vai basicamente viver colocando "use client" em seus componentes. Da pra se ver que o React está focando muito em te fazer utilizar os recursos nativos da biblioteca. Por um lado é legal saber que tem solução nativa, mas por outro, faz vc perder boa parte da ideia do server components se tentar usar algo externo ao React. Eu particularmente não vivo sem meu Redux toolkit, e migrar pra context acaba sendo chato por agora kkk

[@danielsouza1824]

Poderia fazer um vídeo sobre server components e client components sem o Next, com o React 18?

[@GabrielSestrem]

O Diego, muito bacana explicar e inclusive estamos na empresa muito receosos de migrar toda nossa arquitetura da pages directory para app directory. Sabes que dá pra colocar server component dentro de client component via children no context é essencial. Agora eu ainda não consigo ver como implementar isso. Eu acho muito mais verboso do que o classico getServersideProps. Me exige quebrar a pagina em dezenas de componentes isolados. Enfim, #medo de mudar tudo inclusive de paradigma

[@airtonsena10]

show 🚀

[@filipe4858]

Seria interessante um conteudo sobre autenticação usando server e client components

[@euigor_santoss]

voce é show

[@markqsantos7613]

O cara já tem que ter uma bagagem para acompanhar esses vídeos da rock😢

[@davkuk2024]

Boa noite, poderiam fazer um vídeo sobre como integrar uma API Graphql com o nextjs usando o appfolder.

[@husky3253]

🔥

[@venomastronomic1888]

qual é a extensão que usas para as pastas no VSC? fica tudo mais organizado e mais bonito

[@lehinfo]

Qual client terminal usas, diegão?

[@giovane6521]

Essas partes da aplicação q usa o lado do client side elas não são lidas pelo SEO? Somente as partes q são server side né?

[@lucasreis9210]

que navegador é esse q vcs estao usando na rocketseat?

[@alexandresoffiattisantos9139]

Tem algum pacote do react que pode ser utilizando para criar dashboard?

[@geanmateus821]

Qual a fonte que ele está usando no editor ? Cascadia Code ?

[@TheIguana3d]

Olá Diego muito bom o vídeo, qual é esse tema que você está usando no VSCODE? Um abraço!

[@dieegosf]

Min Theme

[@gabriellima3930]

Parece o Min Theme

[@TheIguana3d]

Opa bem bacana, parece que é esse mesmo, vlw pessoal !

[@TheIguana3d]

@@dieegosf vlw Diego ❣️

[@guilhermecampos7920]

Eu gostaria de saber quais sao os sites e as referencias que o Diego usa para se manter tão atualizado

[@joaogustavoferreira7136]

Documentação das LIBS, acompanhar os Updates e artigos dos criadores e desenvolvedores, seguir a comunidade. SABER LER EM INGLES

[@mirtonribeiro2706]

Gostaria que voltasse com o projeto do reactflow e explorasse mais aquela biblioteca adicionando mais funcionalidades aos nodes

[@RaueAraujo]

Salveee

[@guilhermeferreira6607]

Qual snippet voce usa?

[@arozendojr]

Qual padrão nomes usados no CSS é adotado no REACT e se são os mesmos usados no REACT-NATIVE? OOCSS, SMACSS, Atomic CSS ,ou ITCSS

[@borgotchongo]

Eu vou acompanhar sua dúvida porque fiquei curioso também. Mas na minha, isso depende muito do projeto. Isso é mais uma escolha do que um padrão. Se for utilizar Tailwind por exemplo, já meio que foge de qualquer uma das opções que você sugeriu. Ainda tem projetos que usam CSS Modular, mas nestes casos até da para encaixar outras metodologias. Ainda sim, com tudo o que vi até agora (não sou especialista front), acredito que Tailwind parece ser a melhor opção a ser seguida já que ela isola a aplicação do estilo direto no componente, evitando efeitos colaterais de estilos em outros lugares, não precisando assim utilizar metodologias como SMACSS e Atomic nestes cenários. Mas vou ficar de butuca aqui para ver outros comentários! hahaha

[@AndresJesse]

com esses novos "power ups" client side, vai ser inevitável criar uma arquitetura boa pra gerenciar as ações Server side chamadas de dentro dos componentes. Acessar o banco direto do componente vira bagunça e abre muita brecha pra falhas, por exemplo. O que vocês acham que vai ser viável, criar um "mvc" dentro do next? implementar um pattern tipo repository? ou algum outro tipo de camada intermediária?

[@user-to4or3rq8l]

Outro dia estava testando umas possibilidades. Segreguei a lógica da aplicação em camadas de domínio com entidades, serviços e repositórios, usando OO e inversão de dependências (bem no estilo Node/Nest), evitando ao máximo vazar a lógica de negócio pra camada de visualização (componentes React). Gostei do resultado, mas sinceramente não faria algo sério totalmente dessa forma, sem um backend real.

[@AndresJesse]

@@user-to4or3rq8l excelente. Aqui também só usamos next com backend isolado (laravel). Em alguns projetos menores eu deixo os alunos criarem tudo no next com prisma, mas confesso que a abordagem é ruim. Pra mim o next é um excelente gestor de frontend, um BFF na verdade.

[@davidartagnan2219]

Não sei, mas quando se trata de server components me surge uma dúvida: Num mundo onde a tendência é termos 'clients' cada vez mais robustos para rodar uma aplicação, por que a necessidade de colocarmos o trabalho no lado do servidor, sendo que muitas vezes isso pode significar aumento nos gastos da máquina locada? Não faz sentido colocar mais trabalho no lado que tem custo.

[@dieegosf]

Entendo a linha de raciocínio, mas custo não necessariamente é definido apenas pelo tanto que você gasta de servidor, concorda? Por exemplo, vamos pensar uma empresa grande como uma Amazon da vida, o que é mais custoso pra Amazon entre demorar 500ms a mais pra página ser carregada pro usuário ou o custo de servidor envolvido para esse mesmo processo demorar 100ms? O ponto é que muitas vezes uma experiência de usuário ruim é mais custosa do que alguns dólares de servidor, ainda mais que o processo server-side feito pelos Server Components não deveria ser custoso, ainda mais rodando em mecanismos de edge computing.

[@miguelcassimiro8103]

Nessa nova versão do Next eu estou utilizando o Zustand para salvar algumas informações do usuário logado para controlar a sessão (ao invés de buscar cookies toda vez que acesso uma página). Seria essa a melhor abordagem para client components? Ou existe algum meio de controlar isso pelo lado do Servidor?

[@gg.martins]

O zustand está do lado do client, não tem como resgatar informações dele em server components. O pessoal achou umas gambiarras para que um server component popule uma store do zustand (podendo usar entao a store em múltiplos server components), ai você passa os dados também pra um client component como props, e esse client component atualiza os dados que o server pegou para a store do zustand, mas isso pode causar alguns bugs pois se o mesmos servidor responder a diferentes usuários os dados na store do zustand seriam os mesmos da outra requisição (já que isso estaria na memória do servidor e ele não controla sessão de cada usuário). Uma verdadeira zona. Até agora pelo que entendi os server components para uma aplicação normal atual que usa reactjs deveriam ser usados pegando informações de cookies ou então recebendo props de algum client component.

[@teliiz]

Qual dificuldade de converter um reactjs para nextjs

[@thiagobraddock3372]

E esse component async lida com o ciclo de render diferente do React puro? Os disparos de alteração do state não causam um novo request nesses fetch? Sem necessidade de useEffect eu quero dizer

[@guilhermenunes2440]

Os ciclos de vida do react não "existem" em server components, o Diego exemplifica isso ao refatorar o CountButton em um componente separado. Se você utilizar qualquer hook do React (useEffect, useState, useMemo e etc), vai receber um erro no build. Acredito que o conceito aqui é de que o Server component é mais um componente de "visualização", ou seja, não tem interatividade, apenas informações estáticas, e se você precisar adicionar interatividade precisa criar um componente separado, assim como o Diego fez.

[@alefe238]

Eu preciso recuperar um token jwt vindo de um back-end ou dados do context de autenticação dentro de um server component. Teria como fazer isso ? Meu intuito é fazer requisições por meio de um server componente pra não ter que lidar com bibliotecas como react query no client ou até mesmo state e useEffect

[@dieegosf]

É legal salvar o token nos cookies e assim recupera tanto no front e no back.

[@antoniogarcia7373]

Estou usando um server component async onde faço busco dados de um api e acontece tudo certo na primera vez que que aparece a página. Mas os dados ficam desatualizados quando vou para outra pagina e depois retorno a página onde está o server component. Alguem em alguma dica do que fazer para mander os dados atualizados?

[@tarcisioteixeira9045]

E ai @diegão salve. Quando tento usar um async server component, numa pagina recebo o erro que não pode ser usado porque retorna uma Promise. Alguma luz ai?

[@lucasdias1348]

Sem o código fica difícil de ajudar amigo.

[@tarcisioteixeira9045]

@@lucasdias1348 Resolvido já. Era problema do TS, tinha que passar um comentário expect @ts error

[@thiagodiniz8224]

Primeiro

[@henryfranz6387]

almoço completo

[@rariber]

stitches, press F to pay respect.

[@lucaslicar3713]

porque?

[@rariber]

@@lucaslicar3713 huehue me confundi falei o nome da lib errada 😅stitches

[@andersonpgs]

qual o tema do warp?

[@gg.martins]

Eu posso estar perdendo algo, mas sinto que tá todo mundo fingindo que não faz sentido eu precisar usar um valor do meu context (ou de uma lib de global state mngmnt) dentro de um server componente? Imagina que minha aplicação o usuário tenha um painel administrativo de várias empresas, para visualizar o painel de cada empresa o usuário tem um seletor no topo da página com as empresas que ele tem acesso. Quando ele altera a empresa setamos num context o id da empresa que ele está visualizando, e utilizamos este valor em todas requisições para a API, por exemplo. Como fazer isso? Como fazer com que um server componente faça a requisição para minha api, utilizando o id da empresa que o usuário selecionou em um client componente e que está num context? Ou até mais bobo, supondo que eu salve o token do usuário em um context da vida, ou até mesmo no localstorage (que um server componente não tem acesso), como utilizar essa informação lá? Me parece estranho que o local onde deveríamos fazer nossas chamadas para a API não tenha acesso à uma informação que teoricamente vem de uma interação do usuário. To viajandasso? Ótimo vídeo, como sempre. Valeu.

[@dieegosf]

Fala @gg.martins, beleza? Então, com Server Components muitas vezes a gente tem que mudar um pouco a maneira de pensar nas coisas. Por exemplo, com Next, é legal tentar evitar o local storage pra esse tipo de informação e usar cookies que são acessíveis tanto no cliente quanto no servidor. Mesmo assim, lembre-se que a ideia é encapsular os client components ao máximo, se possível, ou seja, se você tem um server component que precisa de uma informação de um contexto você precisa pensar "será que consigo separar a parte que precisa desse contexto em um componente menor?" se sim, então separa, se não, tudo bem, a ideia não é você ser proibido de criar client components.

[@IgorAlves15]

Se precisa da informação do localStorage para fazer a requsição então não pode ser um server side componente ? O jeito seria fazer com useEffect como antes ? Bah agora vc me deixou na dúvida kk

[@joaovfsousa]

Qual app é usado pra gravar a tela e criar as diferentes cenas(se isso não for fruto da edição)?

[@dieegosf]

O único app que uso é o Mini Video Me pra câmera: github.com/maykbrito/mini-video-me De resto é apenas gravação da tela e edição.

[@BrocchiRodrigo]

Quem tem "reclamado" de Server Components; Também comento que usei essa abordagem em dois últimos projetos e na boa, tem resolvido uns problemas com efeitos colaterais que antes era um P.. problema no React, fora a performance que ficou massa. Tropecei em alguns bugs e libs que não acompanharam a transição ao mesmo tempo, mas algumas já foram corrigidas como é o caso do Next Auth, inclusive descobri recente que da pra passar a sessão por dentro do provider, diferente do que está na doc, e isso resolve um dos poucos problemas que eram embaçados. (ainda não tem compatibilidade com Edge para usar adapters infelizmente). Supabase, pacote Next Helpers está com uns bugs bem ruins e tem vulnerabilidade até a data de hoje, porém o pacote ainda está em beta. Quanto as libs de estilos css-in-js, "RIP" ainda rs, mas da pra contornar muito bem com Tailwind e algum pacote de UI (ou alguns). Aquele que o Diego recomendou (shadcn), é uma boa, inclusive os components prontos de form... Que maravilha cara... Da pra combinar com outras coisas como o magicuikit, entre outros, então styles não é problema.

[@Nicolas-dz1pn]

"da pra passar a sessão por dentro do provider", consegue explicar melhor ou dar um exemplo? Pelo que eu vi por issues e discussions do repo deles vc nem passar a sessão pro provider vc passa, pq querendo ou n aql sessão q vc passa era mais pro primeiro carregamento da aplicação, então n gera problemas n ter o parametro no provider. Assim, talvez eu esteja confundindo oq vc falou, mas eu n acho que vai fazer mal perguntar pra entender melhor

[@joaopedrobragaporto1476]

@@Nicolas-dz1pn Você so cria essa sessionprovider se quiser usar do lado do client(useSession do next-auth), tu pode pegar (lado do servidor) getServerSession(authOptions) . Cria em uma pasta separada essa função toda ja retornando as informações do usuario ... kzbin.info/www/bejne/n4jPgHtuZ7-FabM

[@susanoo4081]

Qual a extensao de snippets que voce ta usando pra criar os componentes?

[@bernardonunes2942]

tbm to querendo saber

[@YuriEdmundo]

também to querendo saber, ele parou de usar o snippet da rocket porque o da rocket cria como const e esse como function

[@susanoo4081]

@@YuriEdmundo sera q foi ele q criou? tentem achar ai e me falem

[@eskstyle]

na dúvida tbm...

[@instrumentality2999]

querendo saber tbm...

[@mateusbolito]

Cara o futuro vai ser todo mundo sendo obrigado a ser full stack com salário de junior. Ta ficando complexo o front end, mas faz parte infelizmente.. aquela separação so de criar tela bonitinha ta ficando pra trás kkk

[@matheusdeoliveira3303]

Hoje, há algo que substitua a lib framer-motion para os server components?

[@dieegosf]

Animações são client-side sempre então é só usar client components ou fazer as animações por CSS puro

[@matheusdeoliveira3303]

@@dieegosf performaticamente, vale a pena sacrificar um server component para utilizar a lib de animacao? Ou é melhor utilizar o css puro?

[@gg.martins]

Como eu faria em um server side component para mostrar um toast de erro caso alguma chamada à api falhe por exemplo?

[@dieegosf]

Se for uma chamada a API que dispara assim que o componente é criado como um carregamento de uma lista de dados, você não exibe toast. Se for uma ação do usuário, tipo "Deletar produto", você pode encapsular esse botão de Deletar Produto dentro de um client component.

[@mauriciomira2]

Estou inserindo um server component dentro de um client usando children, e estou recebendo o erro: Error: Server Functions cannot be called during initial render. This would create a fetch waterfall. Try to use a Server Component to pass data to Client Components instead.. Alguém sabe oq pode ser? Já gastei várias horas nesse problema rs

[@carloshenriqueoliveira79]

seguinte, é uma sla ideia ou comentario não é uma verdade absoluta e sim algo que eu gostaria de sla participar ou saber como faz pra fazer. como é que eu faço uma ferramenta dessas. tipo, tem react js react native e uma caralhada de outras coisas. como eu faço pra ter algo parecido com isso. isso é grande sim e muito mas eu tenho isso, de algum tempo da vida usar algo escrito por mim pra mim mesmo entender o que rola por baixo dos panos no c a gente aprende que um array é de tamanho unico não é como a gente ve no js mas então o C é mal feito? não, quando a gente faz um push estamos copiando o array na memoria e colocando um elemento novo nele no final e por fim setando o array anterior como null ou algo assim pra ser pego depois. então de grosso modo no C a gente tem que fazer isso na maão ? na real eu nem sei kk só sei que no js node react tudo que usa javascript eu uso .push(aqui eu coloco o que eu quero adicionar no final do array); e pronto ta feito ksksks como fazer ferramentas. isso é o que eu quero estudar neste final de ano. tipo sla uma janela preview que atualize automaticamente assim que eu salvar o meu sla index.html por exemplo.

[@pedrotolentino8082]

Faz video utilizando o zustand

[@luki8932]

Essa mudança me faz pensar, o que é melhor em questão de perfomance, uma requisição enorme no index que passa as props para todos os componentes, ou dez / quinze requisições separadas por componente

[@user-to4or3rq8l]

Normalmente eu prefiro requisições menores e espalhadas por componentes, usando estratégias de loadings parciais. A sensação de performance pra quem está usando sua aplicação é melhor. Mas claro, não são todos os casos onde isso é possível e da um pouco mais de trabalho fazer.

[@AndersonSousa33]

As duas primeiras coisas que eu observei: o tema e os ícones ahahahah quais são?

[@Black_9]

Acho Next promissor, mas quando usei em projetos reais, tive que aprender tudo essas abordagem diferentes, o que me fez passar pelo fim do mundo em código, outro foi ter que aprender Tailwind, certo eu posso usar um sass + modules, mas não é mesma coisa de um Styled-components que eu facilmente passo props e faço qualquer coisa. O lado bom foi que aprendi muita coisa, o Tailwind me ensinou algumas coisas de css que ajudou no meu css puro, fora padronizar. Voltando sobre Next, conserteza vou ter dor de cabeça ainda, por enquanto as que eu tive foi em projetos simples, agora em alguns mais complexos conserteza vou sofrer.

[@cbtcnl]

Você já atua no mercado? Estou começando a estudar framework, e já estou pegando os conceitos do next.js dentro do react, pra mim está sendo mais fácil integrar tudo junto, do que aprender as tecnologias separadas, o conteúdo da Rocket é divisor, pq mira certo, queria a visão de dentro do mercado, as empresas já estão implementando o uso dessas tecnologias?

[@uesleisuptitz]

@@cbtcnl Opa, estou atuando agora mesmo em uma landing page com Next + Styled Components + MUI.

[@marcospadilha3634]

😯@@uesleisuptitz

[@danilochgs]

Qual foi da mágica pra criar componente?

[@dieegosf]

Um snippet apenas

[@ojvribeiro]

Isso aí provavelmente é um custom snippet do VSCode.

[@NandojrBFR]

Que tema é esse que o Diego está usando no Vscode?

[@Nicolas-dz1pn]

Me parece ser o min theme (n sei se esse é o nome exato to com meu vs fechado)

[@maxwellalves6492]

se um componente pai, tiver a diretiva de 'use client', todos os filhos serão client tbm? exemplo o filho recebe uma prop de estado do pai, cada vez que ele atualizar o filho tbm atualiza, mesmo sendo server component?

[@DjEdu28]

Pelo que ele mostrou no video, todos os filhos são tratados independentes. conforme o contexto onde foram declarados

[@dieegosf]

Não, mostrei isso no vídeo. Você pode ter server components dentro de client components, só precisa lembrar de passar esses server components pelo children do client.

[@leandromoraes1862]

Essa arquitetura serve para o react native?

[@dieegosf]

Ainda não

[@GabrielSilva-en4qp]

Qual o nome dessa extensão q so com a letra c ja cria a estrutura do componente?

[@dieegosf]

Criei um snippet próprio

[@GabrielSilva-en4qp]

@@dieegosfbrabo

[@samuelblack10]

Primeiro na quarta colocação

[@felipelima-cl4vu]

Qual o tema de ícones do vscode ?

[@user-oq8bs3by3h]

Symbols

[@DevJonasGuedes]

Se chama: Symbols

[@luccabassoli]

@@DevJonasGuedes Qual o tema dele?

[@gustadev276]

@@luccabassoli Min theme

[@xsamuelx3603]

:)

[@eriiklima]

Third!

[@diogosoares6546]

Não tem nada haver comparar com PHP, quem ta fazendo isso é os haterzinho de react, vercel e javascript da vida, ninguem sério que eu considero ta falando isso, alguns so repetem o que ouvem, sou Dev40+ isso ta longe das antigas paginas com PHP ou ASP na eṕoca.

[@00xfitx2]

muito bom ver um dev mais velho que não é alienado, a maioria do povo da tua idade ta cagando regra hahahah

[@miguelbizzi8384]

Qual o nome da extensão paara deixar as pastas assim

[@dieegosf]

Symbols

[@rafaelucaas]

Qual tema do vscode é esse?

[@dieegosf]

Min Theme

[@rafaelucaas]

@@dieegosf Valeu! 👍

[@joaovitorgruppo2379]

Qual é o tema do vscode?

[@luccabassoli]

Também quero sabe kkk

[@gustadev276]

Min theme

[@caiolacerda414]

alguém sabe o tema que o diego utiliza?

[@dieegosf]

Min Theme

[@diogosoares6546]

E na moral fazer SQL Raw não é algo tao corriqueiro quanto era antes de nascer os ORMs, alias, eu recomendo que nao façam SQL direto senao souber muito bem o que esta fazendo, pq sem saber voce facilita XXS, SQL Injection, Comman Injection e coisas assim, entao.....nada haver essa comparação.

[@ohervis]

Nunca passei tanta raiva com uma lib desde o ember kkkkkk Meu projeto em Next demora muito pra fazer hot reload e muitas vezes chega a travar o PC, o embaçado é que são 3 paginas de aplicação. Estou tentando investigar o que pode ser mas só achei um link do Redit falando sobre isso e uma issue aberta no GitHub. Se alguem ja passou por isso usando next13, por favor, da um help kkk Minhas expectativas agora é que pode ser o Antd design bugando algo, font awesome ou a forma que eu to usando o sass Ja tentei usar o turbo pack também e fica ate pior :/ Daqui a pouco vou migrar pro Nuxt pq ta triste a vida :/

[@uesleisuptitz]

Cara, vou te falar que quando usei Ant Design uma vez, ele entre fazia a aplicação entrar em loop de renderização. Não sei porque, mas sempre que atualizar o código tem que dar F5 no browser para não acontecer. Na época eu n investiguei o caso, mas provavelmente não é algo que você fez.

[@luccabassoli]

Qual o tema do github?? :D

[@dieegosf]

Não é um tema, meu navegador (Arc) me deixa mexer nas cores dos sites.

[@luccabassoli]

@@dieegosf Eu digo o tema do VSCode mesmo kskss

[@dieegosf]

@@luccabassoli Min Theme

[@LucasCosta-el4ip]

@@luccabassoli min theme

[@rafafsantos86]

Coloquei um TextField (material UI) dentro de um projeto básico do next e passou a dar hydration failed :( :( :( Solução... não usar Next...

[@dieegosf]

Ou não usar Material UI haha

[@gg.martins]

@@dieegosf Po, eu entendo que o comentário do amigo foi um pouco ácido, mas a sua resposta é estranha também. Para uma comunidade que estava acostumada a usar diversas libs com o react, uma nova tecnologia simplesmente quebrar a maioria das libs é meio estranho, não? Ou o role é esse mesmo, lançou uma novidade, tudo que quebra com ela deixa de ser usado e vamos construir do zero denovo? :O

[@versaleyoutubevanced8647]

Vc não acha que esse "use client" é uma forma urgente que eles implementaram pra conseguir lidar com server components? Não acho que seja difícil criar uma lógica no compilador pra separar o que deveria ser client e o que é server, e fazer essa distinção sem ser de forma declarativa. Um dia a agente vai lembrar dessa época e falar "se lembra quando a gente tinha que colocar 'use client' no começo do arquivo?"

[@gamey1346]

Tem muito Edge Case para ser tratado, imagina vc faz um componente pensando em ele ser usado do lado do servidor, mas por algum motivo o compilador entende o contrário ? É melhor que seja uma forma declarativa mesmo, pq nos dá o poder de escolha. Talvez no futuro tenhamos um compilador que identifique de maneira automática, mas não acho que vamos deixar de ter um "use client", talvez até adicionem um "use server" para vc forçar o compilador a interpretar aquilo da maneira que vc deseja.

[@gg.martins]

Falar que não seria difícil fazer isso no compilador é loucura, mas eu concordo que parece algo urgente pra entregar logo. Ao mesmo tempo que muita coisa dahora surgiu, muita coisa que já se usava simplesmente não funciona/não faz mais sentido(?) Pra mim a própria narrativa ficou estranha, não faz sentido pra mim um framework de frontend (em cima do react!!!!) trazer algo que por padrão você não consegue nem usar um botão, ou um useState... Não soa bizarro? Seila, posso tá viajando, mas eu acho a mesma coisa que vc, daqui um tempo vamos usar todas APIs do react em server componentes e achar bizarro essa versão atual.

[@matheusdesouzaribeirodias5666]

@@gamey1346 inclusive, já existe uma feature experimental chamada server actions, onde você pode criar uma função assincrona antes do componente. Nela precisa usar a diretiva 'use server' 😅

[@versaleyoutubevanced8647]

@@gamey1346 sim, por isso vejo essa abordagem de agora como algo urgente, se fosse fazer dessa forma automática ia sair next com server components só em 2024, 2025

[@versaleyoutubevanced8647]

@@gg.martins o compilador ja sabe diferenciar client e server, tanto q quando o componente precisa ser client ele lança um erro avisando, é partir dessa lógica adiante.

[@guilhermemaffei6532]

A unica coisa que não gostei são os Next handlers, que substituem as antigas api routes. Me parece muito trabalhoso e confuso fazer qualquer coisa, extrair um body, ou pegar os parêmtros. Não gostei

[@jameskjr]

"a gente"

[@noriller]

Eu não confiaria em pessoas não fazer algo que não deveriam fazer... Se ta lá, se da pra fazer... pessoal vai se pegar pensando: "é uma exceção, não tem problema" isso até virar regra "todo mundo faz assim..."

[@dieegosf]

Ah, vai ter gente que vai fazer, mas logo vira má prática, como aconteceu com todas linguagens.

[@Cahnisama]

Existe jeito certo?

[@dieegosf]

Claro!

[@BlazeReap]

Todo dia uma coisa nova no mundo js... Namoral ta mais interessante ficar em coisas solidas que tem alguma novidade de 6 em 6 mdzss ou de ano em ano como .NET doq esse trabalho chamado javascript

[@DanielBergholz]

Eu mesmo to largando o frontend pro Ruby on Rails, não aguento mais ter que migrar meu frontend inteiro a cada 2 meses

[@deboacas]

Não vou negar, isso está passando pela minha cabeça. Ou focar totalmente em backend, dados e cloud

[@lucasdias1348]

Tá muito instável mesmo, tô estudando nextjs desde o ano passado, apesar de já vir do react, todo mês tem uma coisa nova pra se aprender, eu comecei com PHP, migrei pro react porque curti muito o framework, mas já não estou mais. Essa mistura de querer fazer client server tá uma merda.

[@brunoamorim649]

Diego usa zustand

[@rotivanov]

Components se pronuncia com enfase no segundo O. compOnents e nao cOmponents.

[@dieegosf]

Fisk fisk, inglês e espanhol é Fisk!

[@brunocipolla3209]

não é muito suspeito uma empresa de CLOUD desenvolver um framework em cima de uma client lib e criar um ecossistema enorme pra evangelizar server components? kkkkk Infelizmente a comunidade JS é a mais perdida e desunida de todas :( já poderiamos ter soluções muito mais robustas do que isso

[@gg.martins]

Aleluia. Não soa estranho vc estar usando react e por padrão agora você não pode nem usar um botão, ou um useState? kkkkkkkk eu to maluco?

[@dieegosf]

Apesar de ser algo novo no React, não é algo novo em outras tecnologias, então existe esse movimento de forma geral na comunidade front-end. Alguns frameworks como Fresh (do Deno) e Astro implementam essa separação de client e server components com um mecanismo chamado de Islands ( docs.astro.build/pt-br/concepts/islands/ ) ( fresh.deno.dev/docs/concepts/islands ) enquanto o React chama isso de Client Components. Ou seja, simplemente julgar que isso é uma jogada de marketing seria novamente irresponsável da nossa parte já que é um movimento comum no front-end como um todo.

[@lucaslicar3713]

e se for? eles estão trazendo uma solução e querem ganhar o deles kkkk, se não gostar é só não usar

[@helamaewerton6860]

Independente disso, RSC foi uma das melhores coisas nos últimos anos pro React

[@helamaewerton6860]

​@@gg.martinsaté pq interação com o usuário e gererenciamento de status pro lado do servidor é impossível né. Não é pra usar Server Components em tudo, no que for Server você usa, no que for User for usa user. O mal da galera é não estudar a documentação e falar besteira

[@DanielBergholz]

Minha opinião: Devemos parar de uma vez por todas com esse papo de "não adianta nadar contra a maré". Se a maré toda ta indo pro lugar errado, precisamos falar NÃO, e apontar todas as inconsistências que estão cometendo. A comunidade JS precisa urgentemente de mais senso crítico, chega de engolir cegamente tudo que a Vercel joga pra cima da gente Eu discordo completamente com esse approach de mover todo o frontend pro lado do servidor, parece que o Next.js não sabe mais pra onde ele quer ir, e acabou ficando num meio termo horrivel entre client-side e server-side. Agora todo criador de lib ta tendo que mudar a lib dele pra funcionar no navegador e no servidor, por exemplo: Next-Auth so funciona o login/logout no cliente, styled components só carrega no cliente, TA TUDO QUEBRANDO. Outro problema: Next e Remix são server side, você agora vai ter 2 servidores rodando? 1 com o seu backend e 1 com o frontend Next.js? Parabéns, vc acabou de adicionar um overhead na sua comunicação Quer usar o React? Beleza, fica no seu canto aí dentro do navegador e deixa o backend separado no servidor. Não quer usar o React? Melhor ainda, só usa o Rails, Laravel ou Django com o frontend MVC raiz renderizado no servidor, sem todo esse overengineering do Next e Remix

[@dieegosf]

Fala Daniel, entendo sua opinião. Concordo quando você diz que nosso papel como comunidade é opinar e discordar e, para isso, que existem RFCs, inclusive a sobre Server Components está aberta desde 2020 e teve pouquíssima participação Brasileira nas discussões. Por outro lado, quando você cita o Rails como um bom exemplo, me lembra muito nos anos 2010-2012 quando o DHH liderava o desenvolvimento do Rails quase que como uma ditadura, tendo praticamente 3-5 core contributors no projeto guiando para onde TODA comunidade deveria caminhar, sem discussões. Não te parece um pouco o que está rolando no React? O próprio lançamento do Rails entre a versão 2.3 para 3.0, você lembra o tanto de mudança que houve na comunidade? O tanto de biblioteca que quebrou? Ao mesmo tempo, lembro do lançamento do React lá por 2013-2014, a quantidade de aborrecimento da comunidade por estarem "matando" a forma que já estavam acostumados a trabalhar com front-end, querendo trazer mais responsabilidade, mais complexidade e, agora, 10 anos depois, vejo um movimento semelhante acontecendo com Server Components. Acho que o Next nesse momento foi alvo principal das críticas pelos holofotes envolvidos, mas vale lembrar que TODOS frameworks front-end estão caminhando para as mesmas soluções, principalmente voltadas a Server Components. Sobre a discussão de usar um MVP raiz, não vou entrar no mérito e repito o que eu disse no vídeo: a gente não caminhou 10 anos de estrada no front-end para entender que construir HTML com template engine é melhor, não não... Sobre ter dois servidores separados, isso não implica diretamente em nenhum overhead em comunicação. O ponto é que HOJE eu sei que com DOIS servidores eu consigo dar uma experiência melhor pro meu usuário enquanto tenho menos custos comparado a quando eu criava a mesma aplicação com front-end totalmente SPA. Eu sinto que SIM, as pessoas estão cansadas de tantas mudanças. Eu concordo com isso, faço parte desse grupo em alguns momentos, mas TALVEZ e, somente talvez, essas mudanças sejam necessárias. Acho que o nosso principal papel no fim das contas é melhorar a experiência do usuário no fim das contas e, se pensando nisso, você escolheu as tecnologias, está ótimo.

[@NikoKlebtz]

De onde você tirou que está tudo quebrando? A nova arquitetura é opcional tanto para libraries quanto para quem usa diretamente, se você tem um projeto já em produção é só continuar usando a mesma arquitetura de antes e ir migrando aos poucos, se você não vê necessidade de mudar melhor ainda, não precisa fazer nada, tudo isso que comentou só é válido se você quer ficar usando hype o tempo todo.

[@gg.martins]

@@dieegosf Como tens menos custo com dois servidores?

[@talyssonlima2820]

@dieegosf sempre vai está do lado de lá, sempre abraça tudo, e quase nunca escuto críticas.

[@viniclunc8553]

a única coisa que se absorve com a Rocketseat é ansiedade. Nenhum desenvolvedor precisa aprender a reinvenção da roda a cada semana como esses caras vendem... pior que tem gente que ainda compra ...

[@marcospadilha3634]

Salve meu querido. Não sei qual a sua base para dizer que eles "vendem a reinvenção da roda toda semana", mas acredito que é mais fácil não consumir o conteúdo deles se você não curte. Eles apenas divulgam as informações das tecnologias que atuamos. Eles não criaram o Next kkkk. Em momento algum desse vídeo foi dito que você precisa aplicar tudo que surge de novo na tecnologia. Inclusive ele comenta do lance do SQL direto no front, que não precisa, que podemos seguir usando o front e a API separados se comunicando (e foi o mesmo que pensei quando li a documentação do Next). Cabe a ti saber estudar, ler com os teus olhos e saber discernir aquilo que se aplica pra ti. Se te falta essa capacidade, aí é valido pegar conselhos e referências com quem manja mais que a gente, como é o caso deles. No geral a gente tem é que ser grato, pois os caras oferecem muito conteúdo gratuito e de qualidade - que me ajudou a entrar no mercado e evoluir muito até hoje, inclusive. Não só eu, mas muitos colegas atuais e passados e muitos outros aqui no chat. Da minha parte só gratidão, afinal eles não tinham obrigação de ajudar ninguém. Eles tem conteúdos pagos tbm, que é justo (pois investem tempo e dinheiro nisso), mas só dos caras estarem oferecendo um conhecimento que ficaria pesado pra quase todos nós pagarmos, já tá show. Mas repito, se tu não curte, é teu direito. Porém não tem uma 4rma na tua cabeça obrigando a consumir o conteúdo deles. Tem muito dev bom e conteúdo grátis e pago pela internet. Boa procura.

[@ellsonmendesYT]

Diegão sou seu fã kk mas ao invés de pronunciar com-po-nents como proparoxítona faça como paroxítona rsr ao invés de COM-po-nents fale com-PO-nents só mais uma coisa, sabia que eu sei todos os caras que fazem vídeo no youtube que aprenderam contigo ... comenta aqui que te digo como rsr

[@salamandery]

nao vi diferença alguma.. a gente ja fazia tudo isso.. a diferença que agora isso tem nome.. e ter q colocar o use client

[@pedrobenicio4955]

...E assim o frontend vai ficando cada vez mais complexo. Era até simples só com react.... Neste ponto, não estou gostando do caminho que o NextJS está percorrendo (Embora eu goste do nextJS atualmente)

[@wesleyXis7]

Creio que o ideal para nós programadores é estudar "tudo" que estiver ao nosso alcance. Quando entrei nesse mundo era apenas HTML, CSS e JS aliado com o React! E esse era o combo e acabou... Hoje você tem que saber de tudo um pouco e, me pego na certeza que o front end web vai acabar... Uma hora vai ser Full Stack apenas! Algo muito parecido com o que acontece com o dev mobile hoje.

[@pedrobenicio4955]

@@wesleyXis7 fullstack ja é realidade pelo menos no nextJS. Acho que o frontend nao vai acabar...Mas é tendencia sim o fullstack e isso vai ganhar cada vez mais força. O frontend ficará parecido com uma linguagem legado, onde ainda existe aplicação no mercado a linguagem, com vagas e tal, mas longe de ser uma solução de "última geração"...

[@juloko]

E esse erro fictício do Diego. Claramente fingido, sabemos que o Diego é incapaz de errar, isso foi apenas um erro introduzido pelo marketing, pra deixa-lo mais humano.