as someone who's watched many many Seb and Andrew talks over the years, i feel like they're really nailing the fine line between communicating React principles and not getting too dragged down in the implementation detail. kudos to Delba as well for moderating such a well balanced discussion!

Thank you so much, I am from Madagascar. You are doing a great job helping developers around the world.

@cowabunga2597

Жыл бұрын

Madagascar like that movie ?

@mianala

Жыл бұрын

@@cowabunga2597 yes 😅

It brought us the clarity about approaching the composition of components and deciding actually which component should be on client. It's better to think react declaratively. Questions asked are solid, on point.

Love all of you on the screen 🎉

Before server components, we use js to call the backend server. Developers manage only the client end. With server components, while it cannot replace the backend server, it create a front end server to call the backend server for you. And now develops need to take care of both client and frontend server. Extra work for not too many benefits (fewer load time)

@IDOLIKIofficial

11 ай бұрын

I don't know, bigger projects will always be separately done since they are usually more complex and usually you'll offer api to some external clients.

I know what to watch tomorrow 🤗

shout out to both, Andrew and Sebastian.

Great talk

Love these guys

Please make it possible for us to getActionData on initial render before js is available

Great video

I would listen to Andrew talk about Server Components for 10 hours

I'm a frontend engineer, and at my current workplace we have a distinct set of teams that work on the FE / BE primarily because we use a Java backend. I'm just wondering how I want to go and talk about Server components with the backend folks. Telling them that data fetching to the DB can now happen via an ORM of choice within the server component :). As in your taking away what they did in the data fetching endpoint project, and combining it with Server components. Any suggestions ?

@butadpj

Жыл бұрын

As per server components RFC, "The goal is to be able to scale up or down and not rewrite your entire app". If you already have an existing endpoint that fetches data from your db, great! With server components, the server is going to fetch data for you and whatever sent down to the browser is the actual html elements or component that has a complete data, *not some blank html unless you run the JS code that fetches data and build the trees of elements*

@rand0mtv660

Жыл бұрын

Nothing should really change for you except that same fetching can occur on the server in a way that's more integrated into React and not specific to a meta framework like Next or Remix. People mention these direct DB calls a lot when talking about Server Components, but that doesn't take into account all existing APIs that are already deployed and written in different languages and frameworks. These direct DB call demos and showcases are mostly like "hey, look what's possible now because of Server Components!" and not "hey, this is the only way to use Server Components!". Also, depending on your use case having an actual API project might be the only way to do it because you might have a mobile app or need to have the ability for 3rd party integrators to work with your system so using an ORM doesn't really make sense since you are going to have an API anyway. I would say just continue fetching from your existing API using regular HTTP calls and don't worry about it too much.

@nikilk

Жыл бұрын

Thanks folks. I agree that when you have a stand-alone data endpoint just fetch from that data endpoint.

can you link the demo that Andrew mentions at 32:20?

@VercelHQ

Жыл бұрын

app-router.vercel.app/

Holy Andrew on a video :o

OK, where's the table ?

Thank you for bringing this amazing tool to us developers. and a big thank you to @DeveloperDeck101 , for bringing a commented video in Portuguese about this live and of course for the incredible masterclass he is developing based on the new features of nextJS

I really wish devs could remove "seamless experience" from their vocabulary altogether. As well as oversimplicity such as "a server component is just a component that runs on the server"

@dawidgrabowski6122

Жыл бұрын

thats so true. It sounds simple but gives u none information

@swyxTV

Жыл бұрын

its all about the ✨DEVELOPER EXPERIENCE ✨

can vercel create a NextJS like framework for ReactNative kinda...

I m finding a bit hard to learn this new server components means when to use client when to use server what is the best way to use server how to use I mean I'm getting confused between server and client components

@ralexand56

Жыл бұрын

With next it's server components by default, so you should focus on adding the client directive to a component when you need some interaction at the client level that doesn't require any data from the server, so in general things that use state and hooks should be client components. But try to make it as granular as possible because the less JavaScript you have to send to the component the more performant your app is so, for example, you could make just a button a client component if it just needs to act on local state while keeping the rest of your component tree as server base.

@muhafizahmed9964

Жыл бұрын

@@ralexand56 but even if I add an react icon or styled component it gave me error to add use client so do I have to make another component just for icon and one more question making more client component will decrease the efficiency of application ?

@ralexand56

Жыл бұрын

@@muhafizahmed9964 Haven't worked with those two libraries with Next so I can answer your specific questions. Perhaps those libraries are using context or hooks. I haven't had any issues with Tailwind and heroicons. Making more client components doesn't decrease the efficiency of the app unless you mean having to ship more javascript. Again, some times client components are needed for the best user interaction experience.

@muhafizahmed9964

Жыл бұрын

@@ralexand56 thank you so much sir for helping me out. Is there any way so I can connect with you

But server component will cost a lot of money on serverless function?

Call me cynical ... but ... there seems to be a lot of this "promo" content for server components recently. Here we have both Vercel/Next and React (not for the first time) explaining the pros of server components. Seems to me that despite RSC being around for a good while now, clearly the uptake hasn't been great. Is this a case of the dev community not understanding the concept and/or the benefits? Or is it just that they don't like the concept or even find it necessary? We are creatures of habit for sure and can sometimes need a push in the right direction. But I'm not sure if that is what is happing here. Personally I'm still not convinced RSC are worth the hassle.

@touctouctouctouc3440

Жыл бұрын

What is the hassle?

@caliwolf7150

Жыл бұрын

In a way yes companies that I worked with the oast couple of years don't need server components the struggle is with managing dependiences arrays and places where React fail to explain how things work where on the other hand you don't find these difficulties in other other frameworks im giving feedback from the battlefield here and imo the majority are looking for quality of life improvments like signals or not having to think about deps arrays rather than adding a new complixity to their work flow with RSC

@tomino133

Жыл бұрын

I mean if you have to explain why something is great over and over again it probably is not that great

@krishna9438

Жыл бұрын

agree with you. I still don’t see where “keep large dependencies off the client” is useful for a component. I think the “pages” model is more straightforward: all components are client component (rendered in server, hydrated in client) and put early api calls in getServerSideProps

@jayaif

Жыл бұрын

RSC have been around for a while, but it's been in beta and wasn't very stable. We've only just got access to the mutations api, which is a pretty essential piece. There's also a lot of libraries that don't support it yet.

Love all them! Vercel is the future of frontend development

NextJS all the way oooo

bruh, when page transitions in app router.

For a internally used financial application that doesn’t care about SEO and faster first paint load times I’m not sure if server components will add any value. Why would I want to make a data fetch on the server side and send down a larger payload that consists of a lot of html versus making a data fetch on the browser and going the SPA route of creating html on the browser. Perhaps reducing bundle sizes is one argument but if your caching JS assets on the browser then that’s a mute point as well. It’s probably the folks that care about faster load times and SEO that would benefit the most from Server components ? Like Andrew said it’s another tool we add to our toolset and it’s not something we want to use everywhere.

Glad they invent php

redux and redux-saga was the biggest over engineering ever!!!

"Just add use client". "It's just a component on the server". "It just works". It's not this simple and it's a massive pain to switch and there aren't any DX or UX improvements as far as I can tell. In fact it has certainly made DX worse. I work on a non-trivial sized app and thought maybe there would be areas of the site or code where we'd see benefits and still can find any examples. If your frontend is so bad or so complex that RSC improves things, I would think that perhaps your code sucks moreso than RSC is great

I'm from Brazil, watched it in ptBr by @DeveloperDeck101 😁😁😁