Are React client components bad?
Vložit
- čas přidán 17. 06. 2023
- Should you only be using React Server Components?
◆ Next.js docs: nextjs.org/docs/getting-start...
◆ Incremental adoption guide: nextjs.org/docs/app/building-...
◆ Why do Client Components get SSR'd to HTML? github.com/reactwg/server-com...
◆ RSC From Scratch. Part 1: Server Components: github.com/reactwg/server-com... - Věda a technologie
Would love a video on how to nest the different types of components, how data and state flows between them, rehydration etc.
He doesn't know
@@zksumon847 I think he does but the documentation is not clear and spent 2 days trying to debug a SSR issue. If you look at the Vue3 docs as an example it's pretty clear how the component life cycles and hydration strategies work. I know NextJs isn't vue and is a meta framework but docs similar to how vue3 words it would be nice for noobs.
This might help! czcams.com/video/YQMSietiFm0/video.html
I love how Sveltekit doc puts it right - "If you have a secret (env) you probably shouldn't expose on client, or you want to fetch data before client spins up - then use server"
All other UI interactions are for client.
Thanks, great video!
I wonder every time I want to detect the active state on a Navigation component, I have to make it client-side, right? Is there any way I can calculate the active state without turning it into a client component?
lmfao I literally put this on a prompt (with some edits) on Bard (because it can search the internet):
Prompt:
In Next 13 App Router with RSCs. I wonder every time I want to detect the active state on a Navigation component, I have to make it client-side, right? Is there any way I can calculate the active state without turning it into a client component? Can you say yes or no on "is there any way" question?
Answer:
no
Does caching in the new router only works when deploying on Vercel? Because this seems to be the case with the old getServerSideProps, which also has caching, which seems to only work when deploying to Vercel.
I've created a new side project over the last couple of days and Next.js + server components + server actions + deployment to Vercel allowed me to get this project going in record time 💪 And it even has 99 score on page speed checkers
When the Bandwith supass 100GB prepare to pay 5k ⚠
Great job Lee!
Thanks!
well explained sir lee robinson!
I had difficulty grasping the distinctions between server and client components, as I was under the impression that a server component could not be contained within a client component. This created confusion, as my user profile button required server functionality to access the user database, while being nested within an animating sidebar that needed client-side abilities. However, the solution was to pass it as a child or prop instead of directly importing it.
Once I experimented with this method, everything made sense and functioned seamlessly
The best use case for server components is to limit javascript being sent to the client. The problem is, most third party libraries use hooks so you end up making most component as client component. It looks like astro does it better. Qwik offers an entirely different approach fully ditching hydration and the end result is even better than astro.
oh the horror you will have to code your own carousel 😢 😢
@@user-fr2fm3ri3w why would you want something like a carousel SSR?
How does Next work when it comes to client components that wrap server components? Like if I wanna wrap main layout with Toast component that's using state? Would the children be rendered on server and that toast component hydrated afterwards?
if you want a CC wrap a SC, you need to use the dount arquitecture (aka passing the SC as children of the CC), and yes you can use state if you want, and of course, you can't send props from CC to SC. All SC and CC are renderer on the server, then create a new Tree that is what the client recieve, then CC start rendering.
@@Skinwalker-666 you can wrap a SC in a CC only if you passing the SC as children. Something like this. But you can't call a SC in a CC.
.
nextjs.org/docs/getting-started/react-essentials#composing-client-and-server-components
Ridiculous
@@zksumon847 what?
I am currently developing a Next.js application that utilizes Django for the backend and Next.js server actions. In my workflow, I fetch initial data using a GET request and subsequently update it using a form. However, upon submitting the form, I observe that the initial GET request is re-run, leading to redundant server-side fetching.
I was struggling to wrap my head around the boundaries between server and client. For some reason I thought you cannot wrap a server component inside a client component. And I struggled because my user profile button is a server component as it needs to fetch the user from the database, But it was nested inside a sidebar that can animate in and out, which needs to be a client component. The trick is to pass it in as children or as a prop instead of importing directly.
Well everything clicked when I tried it and it worked perfectly. There is still some edge cases that I am working through, and am starting to come up with personal patterns.
Ridiculous
@@zksumon847 why?
Like the new app router, just struggling with using the metadata api with client components in the app router
I keep getting told that I am not allowed to use it in a client component
Should I go back to using a Head component
Metadata API is pointless outside of server context.
I would be so cool to have an admin ui and data modeling like that in Django, in NextJs
I am using axios for data fetching but getting re-renders errors in server pages and components
you should use fetch instead of axios
@@Rudonn oh okh I will check
What i am really concern about layout. I didn’t find any possible good way to conditionally render layout. Some say to use route groups but how to conditionally change layout for nested page or nested url!! 😢
If you want to conditionally render routes, check out nextjs.org/docs/app/building-your-application/routing/parallel-routes
@@leerob that doesn't actually solve my issue. like i want to show a layout for my "/article" page but a different layout for "/article/[articleId]".
@@shahariarniloy8935 just use pages, you don't need layout in this usecase
else you can still make the required directories and add the required layouts
Lee we are waiting css-in-js libraries to work with app directory. )) But in general , app directory is a lifesaver.
There are already some that have added support: nextjs.org/docs/app/building-your-application/styling/css-in-js
First comment!!! Thanks for the informative video.
we need more videos from you
Editing another one right now :)
Thank you
what is alternative of context and global state in server component?
i like to use cookies
@@jeheskielsunloy3881 cookies are client side not server
It depends on what kind of state you're trying to hold. Is it state that should live on the server (or database)? Could you store it in the URL? You can also continue to use context with client components, as well. As mentioned, this is okay!
@@leerob the exact same as redux or context api sharing state between components without prop drilling but for server component
@@zakidzz The component state is not a thing on the server. The server has to render a final html string for the streamed response, not a DOM. Therefore all dynamic logic can only work upon hydration on the client.
how do you test these components?
By writing e2e tests.
Is the pages router will be deprecated? should i start migrating to app/
It won't be deprecated for a long time. You can move as you're ready.
@@leerob thx
Waiting to see Storybook and SCSS to work together in Nextjs
That won't happen before your death
Page directory feels already dusty. Love the new app directory with server and client components. Thank u 🧡
Glad to hear it's working for you!
What have you built with the new App Router?
RSC is "PHP like" mental model, that's it.
Can you guys make guides or make docs on state management with nextjs 13 app structure?
What state are you curious about? e.g. data fetching "state" is already handled by default in the router. Responses are cached and de-duplicated automatically.
@@leerob Would you make a guide or even added to the existing docs how to handle state management with Redux or Zustand in the new app directory in nextjs 13?
if people think client components are bad, then how can they access window object ?😅😅
Not the main objective of the video, but thanks to showing me how to mark a file has client side
It still didn't answer the question when to use server and client components.
And the answer is use server components for the data which absolutely has to be included in the initial HTML (most of the time it means SEO-related data) and client for the rest.
Client components can still be "pre-rendered" from the server. This is how Next.js works in the pages router. You fetch data on the server, pre-render the HTML, and then hydrate on the client side to make the page interactive. With server components, we're saying you don't need the hydration step for that component-it's purely visual, no interactivity.
github.com/reactwg/server-components/discussions/4
@@leerob Just because they can be "rendered" doesn't mean they will have any useful data to show outside of placeholder in the initial html, either because they derive their state off browser API or uncacheable data.
So if majority of the components will still be "use client". Why doesn't Next have "use client" by default and only prompt "use server" when needed.
Imagine a React app, a framework built for interactivity, have mostly "no interactivity" .
yes
nextjs 14: middleware components 😂
Make client component the default
This video is 4 minutes and 20 seconds long
That has to be on purpose right
nice
I like how this video acknowledges the fact that React and RSCs could exist outside of Nextjs. Oh, wait, it didn't 😅
So far only nextjs implemented them.
@@ra2enjoyer708 "could", not "do"
It's truly depressing to see videos titled like that, after knowing (and using) react as a frontend framework for 10 years.
why?
@@oscarljimenez5717because for 10 years all that React had were "client" components. And now we're talking about if they're bad or not.
@@gotxe I don't see how that's supposed to be depresssing. Tech develops, things change, RSC are a new concept, it's natural to have a discussion on how they fit in with everything else.
@@Svish_ maybe it is, but we're not having that discussion. Instead we're having videos questioning react as a frontend (client side) framework.
What are you smoking? Pure react was never fit for hybrid rendering contexts in the first place, which is a big problem for a hybrid render framework.
The title and the thumbnail are misleading, I was hoping this is something in react core that I didn't know before but no, this video is about next.js. please update the title and include an appropriate thumbnail. (I like next.js, but you shouldn't treat users and customers and developers this way)
+ The title doesn't even include next.js logo, only react logo
RSC is a react spec in the first place and only nextjs implemented it so far.
@@ra2enjoyer708 got it, googled a bit, my bad. Thank you
The RSC and client components appear to be adequate, but in my opinion, they may not be the optimal solution. Developers have been struggling for quite some time to find a solution that enables them to bring a large amount of JS code to the client side, which requires them to implement lazy loading, create chunks with shared features, and now consider client/server components. However, the reality is that it is unnecessary to load all this JS code for interactivity right from the start. The problem lies with hydration. It would be beneficial if React could be more modest and instead of placing the responsibility on the developers, it could address the hydration issue by offering alternatives such as resummability, as Qwik or Marco do. This would ensure that the JS code sent to the client is O(1) and does not grow, even if there are numerous components.
Qwik resummability is great for first interactivity, but right now it lacks of tools handling waterfalls after that. React team is focusing more in fixing the network problems (aka waterfalls) with composition than in reducing the amount of js. Also doing things in the server reduce the amount of js you can send to the browser. Resumability also have a lot of problems when the app is very dynamic and it need to work in a Signals world. Every aproach have his tradeoff. Qwik is far from perfect even if they believe it. If your app is focusing more in client side app and you need that very fast first interactivity, sure, you should use Qwik. But for most dynamic app, SC are a better solution.
The Qwik way shits up initial html with unneeded inline js (therefore bigger uncacheable responses) and bombards the server with extra requests. And calling anything frontend-related O(1) is pretty delirious, especially in context of rendering html.
@@ra2enjoyer708 this inline JS is just few kb and never, the react size is much bigger
@@aralroca "a few kb" which gets added up and never cached.
@@ra2enjoyer708 qwikloader is 2kb. Why need cache if is inline in the html? 🤔