Dan called me to talk about React Server Components...
Вставка
- Опубліковано 29 бер 2023
- React Server Components are dope and I'm very thankful Dan took the time to convince us all that they're great.
EVAN YOU INTERVIEW: • Vite & Vue with Evan Y...
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links - Наука та технологія
I had a call with my mom once, but I don't think that's as cool :(
Depends, is your mom on the React core team?
Your mom > React core team 🙂
@@hamesjetfield0 100 percent
@@t3dotgg 😂🤣🤣
Once? 😧😆
These tools had the intention of simplifying the frontend by abstracting certain aspects of interactions between server and browser, and browser APIs but ultimately things feel like they are getting more and more complex.. My concern is for new devs using these abstractions, how are they going to understand what’s happening under the hood? It’s something to consider as we build these layers upon layers and these framework bundles get bigger and bigger
I guess the end goal is to have abstraction of everything, even the problems, so future programmers don't even need to know what is under the hood. Think of cars, most don't know how they work, but can drive them. That applied to app development
@@remssi-dev but unlike cars, you still have to debug and optimize your programs
@@jalalle1995 yes, that was a bit wrong comparison because of that, many can't fix their cars. But what I meant about abstracting problem solving, is that with high enough abstraction, there can be only certain problems, and those are also abstracted (for example, in form of asking the user to choose what course of action we take)
Every time I hear about server components, I can't help but feel like we might be "over engineering" things. That being said, I don't have a great interest in "full stack" frameworks and still think that the traditional, decoupled REST API backend/JS framework frontend is the best logical choice for almost any app, so I am probably not the target audience.
Speaking from personal experience, they won't.
I think that when a new dev is truly interested in learning how things work under the hood, they will eventually understand it. But if a dev is happy just using the abstraction than they won't learn how it works until they need to.
Dan I just met you,
And this is crazy,
My server components ain't working,
So call me maybe?
Carly Rae for life
Proudly millennial
I think "use client" is more fitting because when we think of servers we usually do so in a server-client relationship. "use interactive" may be more misleading because when you think about it, not all clients have to be interactive.
you can even interact with server components, they’ll just run on the server and thus require a back and forth.
'use client' is also shorter and easier to remember. It just feels right since 'client' and 'component' share the same first character.
I feel like Evan You was making a pretty good case for being suspicious of the route React is taking with Next.
Next and react trying to be a jack of all trades by fuzzying the boundaries between server and client ultimately means they'll be master of none.
Maybe it should be 'use vendor lock in' for server components. That way you know what you're getting.
I actually think that "use client" meaning is "Run on client too" and not "Run on client only"
You are 💯
This whole new paradigm with intertwining server components and client components is kinda tricky for someone just starting like myself tbh.
Take one thingy at the time
At least you have the new React docs. unlike myself 3 years ago 😅 trust me... you got this haha
You got this Maloni! Try and not overwhelm yourself with everything all at once. Take it in small steps. Most complex topics become much easier once you break them down into small, manageable chunks and tackle it one step at a time :) - Just keep going mate, I promise it gets easier.
That was the point Evan You was making yesterday when Theo was trying to sell him more on promoting Nuxt and SSR
Learn js by building a server with express, and building a UI with vanilla js. Maybe play with a template library like handlebars to see how server side rendering with js can look. When you're comfortable with js and understand the differences between server rendering vs doing everything on the client, then start building plain react apps. Then pick up nextjs/server components when you have a legitimate reason to use that tech
Next up on the React feature list: AI components. The component is just a black box and will figure its functionality out from React context.
Exactly the content I wanted to see. Thank you.
Because you have to be aware when your props get serialized and sent to the "client" calling out that fact at the top might not be the worst thing, but yeah it's more like "use server & client but this is too long so we abbreviated it" but also "use interactive"is just more annoying to type out
I agree regarding the 'use interactive' (or 'interactive use' I would prefer) and I will use this in my folder structure moving forward.
I'm curious about your thoughts on RSC and the island architecture
I would love to see a video going deeper about “interactive components”… I’ve been playing around with Astro and it really sucks that you can’t import an interactive framework component into a static framework component without having client:load on the non interactive parent. Would love to know about what forces this behavior
'use interactive' sounds nice. I was wondering if there was any language to borrow from Astro but I don't think so.
How would server know the browser viewport accurately?
I had a doubt about What's the difference between Php with JavaScript for Interactions and React Server,Client Components not in terms of DX ?
PHP: “it’s called knitting, guise…. why do you have to be so mean?”
The react core team is slowly turning into a C++ committee, features and abstractions over abstractions. We can now safely say that React is the Frankenstein of Frontend frameworks
"use full stack" 😂
'use interactive'
Makes sense!
Love React, love Vercel, but I truly hope we'll review this "innovation" called RSC in a a year or two...
Is there a reason why the idea of differentiating between server and client components using only the `async` keyword has been dropped by the React team? I liked how it didn't require any magic strings at the top of the file and how it allowed having both server and client components in a single file.
this is the straight copy-paste from the rfc regarding the introduction of "use client" directive.
---
When a Component with a "use client" directive (similar to "use strict") is imported in a "React Server" environment its exports gets replaced with a special "Reference" object. This object can't be accessed directly in that file but it can be passed into React as if it was a plain component.
React, together with the bundler, knows how to send this reference to the client. On the client it's rendered as a Client component. The real file never actually gets imported on the server.
---
From what I understand, this was necessary because importing a client-side module(which would be a part of a Javascript bundle in production) into the module that's running in the server-side environment would cause a problem.
my guess to "why they dropped using `async` keyword only" is that, it would be risky-ish? in the long run for the server side react to re-evaluate a totally legit javascript syntax to on it's own version , and compare to that, introducing the "use client" is so much easier and risk free? idk just my guess
use interactive is actually more clearer but I think server components and client components are also clear
bravo for the proposal
7:22 but you can also interact with react server components, they just execute on the server instead, and thus require a back and forth.
You can’t
according to the Remix article on RSC's it looks like you can. (I commented the quotations twice now, but the comments won't show here.)
Does the “knitting” produce a sweater with a nice looking pattern, or a sweater with one sleeve longer than the other and random messy patterns with all sorts of yarn colors?
@Theo, would love a video of you doing a demo project with qwik
React has a semantics problem. People are still confused over the whole "don't use useEffect" thing (which was really just the wrong way to say "don't use useEffect manually to fetch data because there's tools better suited that handle the not-so-obvious extras like cleaning and caching) but the core team and influencers have already moved on to the next fuzzy thing - server components. Which do feel fuzzy and complex and not easy to wrap your head around and the answer is "oh it's actually easier don't worry about it". Feels like a big turn off to someone entering the space. I've wrapped my head around server components and I'm excited where we're going but the amount of push back I've received just describing it to others is alarming. IDK, it just feels like react is in a weird spot right now but I think it all comes down to the way we talk about what react is/will be.
Maybe with client is more suitable because by default it run on the server and you extend it with the client
Like HOC
I’m in complete agreement about “use client”. That messed me up quite a bit at first
I like “use interactive”. Much clearer!
Ha! Theo, master of the hot-take as usual
The discussion about server components gets me thinking about what it means for the servers itself. Will this demand more powerful servers, will this mean that running a React application increases the total cost? Client side apps take the load of the servers because you did all the heavy stuff on the client, now more and more will be done on the server. At least this is how I interpret this. Someone who understands this better, please share some loving knowledge :)
You can tell react to build a static bundle at compile time but that would definitely be 'stuck in time', or just 'use client' on every component to get fully client application. 🤷
Even I'm finding an answer to, do we need to keep server running all the time? But that would definitely increase the cost for deploying any react app. May be more event based mechanism would lower the cost but increase the latency for server output. Vercel is definitely going to be the best place to deploy react app in future since there offerings favour these kinds of react application.
the server is actually doing less work than in a current next app using SSR
@@fallenpentagon1579 interesting, Can you elaborate on that?
I think that new React users are having trouble with this concept and usually have problems with server side vs client side because of their education. They usually have no idea how the internet used to work and what serving html directly looks like. At least I know that I can speak for myself and my education.
The solution to this would be to go back to teaching to serve basic html and then introducing reactivity later. That way there would be much less confusion and I think that the new documentation reflecting that is right on point. Is harder for those who learnt incorrectly, easier for the rest and more appropriate for all.
im not a programmer and i have no idea what this guy is talking about
Im know just react for now, I barely got the gist of it all.
how do i hack it
When I open the new official website of react, the first installation method is the nextjs.... This seems to indicate a close relationship between the two
Next with the app directory is amazing. A lot of people are pushing back for production but I think you can use it already!
I find "use client" very confusing too. It took me a while to figure out what was going on. The docs are very clear about this, but not exhaustive. One can miss that details easily. There should be another way of using client-only components besides dynamic imports. maybe "use client-only".
Well 'use client' does make a certain kind of sense.
Everything is a server component.
If you 'use client', you're also using client on top of that.
it's true that it could be confusing for new devs though, from certain perspectives it does sound like 'do this on client' not 'do this on client as well'.
Do directives need to start with use? "Add client" would be more explicit about this being on top of server. I'm certainly not a webpack wizard, barely even know how it works.
eiiiyyyoooo
no homo but skin + shirt + hair really blend well
Best birthday present anyone could give me
Don’t forget the mustache
You previous would kinda neg on Svelte/Sveltekit for being Angular-like, but React/Next is mostly the same with feature bundling from single/dual sources.
in all his thumbnails he looks like he is about to cry
Who votes for "use interaction"?
my man is the next react revolution, witnessing such big changes feel amazing
"usw client"...... nit the first reacts naming miss. memo() is actually cahing function and cache() is actually memoization function.
Dan called you to wish you happy birthday
"use interactive", I completely agree
I hate twitter spaces with a passion. I''m in an EU timezone and regularly wake up to "That was an amazing space! Too bad there's no recording."
RIP
Although I've been following the activity with the new Next stuff and React server components, I don't think I'm right now going to be committing any actual time in learning the new patterns ATM.
Not that I don't think it's interesting, it's just too bleeding edge at the moment. Maybe I'll wait till Next goes through a full version with it, or maybe when the seedlings of decent tutorials start floating around.
Until then very interesting, but I'll only be window shopping.
Bengal tiger shirt > this one
server component
Lets make it even more complicated to not able to understand it by AI xd
Ohh it is easy, we just going back to mvc and call it "server components" to make it sound cool. Same old stuff, new cool name.
@@RaZziaN1 thats the dumbest take I've ever heard lmao. There is almost zero overlap between server components and MVC.
'use-universal'
U ok? You sound a little sick or something. Hope you feel better.
I stopped on "and I didn't record"... 😒
Beware that drastic changes are a gamble. All JS frameworks go through this phase, I am not sure why. Angular did with AngularJS it was disaster. Vue did with Vue3, it was much better but it has had a hit on Vue's growth. Some of the things you are saying sound crazy to me. So much legacy code out there. Most of the time you just want to twik some thing or add a new feature. In my experience
#useInteractive
M U T A T I O N S
The fact that Theo says "interaction boundary" so many times makes me wish for a InteractionBoundary component that works just like the ErrorBoundary component and can be used instead of writing a string on top of a file like "use strict". I never liked that pattern and I think now we have better tools to do that thing
Hi
Loved React when it was class based components only - that simple logic of props/state with few lifecycle methods was a breath of fresh air. So easy to understand and use (even with some problematic parts like mixins). Now it looks like they want to build a framework that solves every edge problem that 90% of us don't have but must live with a complexity caused by it..
"use client" should be "reactive" or even cooler just 'react'
New patterns? People are re-discovering something from 2010 or so.. please, try other technologies, like ASP.MVC which used to do that long time ago.. of course, it was allowed in C# but JavaScript was also allowed.
"use client" should be "is isomorphic" or "isomorphic"
yea lets make it so even less people understand it lmao
As long as Next is the ONLY way to use Server Components, I cannot in good faith push towards such an architecture. At least, a classic create-vite-app ends up with a static HTML/JS package you can deploy in any web server. Since React Server Components *expect* a server that can understand, parse and execute javascript/typescript, then suddenly they become something, well, "not open". Only when React comes up with an official open server model that e.g. can be adopted on at least some kinds of runtimes (i.e. not tied necessarily to Node) then we can have this discussion again. Otherwise, React, for me at least, slowly becomes a Vercel project which is quite annoying - to say the very least.
There are 3 other frameworks with server component support already lol. You can also “next export” a static server component based site. Please try to do some research before such a bad faith rejection of new technology.
@@t3dotgg Do all of these other frameworks also support RSC the exact way according to the React specification, i,.e. with "use server" / "use client" and await-able components? Can I take code from my NextJS "app" directory and copypaste it to Remix et al and expect it to work the *exact* same way without a single code change? Because e.g. I can take my classic create-react-app application (sans routing ofc) and almost copy-paste every file without a hitch in a "classic" NextJS application with almost minimal changes.
Also, I am aware of next export but this defeats the whole purpose of Next (whose whole point is the server side of things, otherwise why not use vite/rollup/parcel/etc, in other words not tied up to a specific bundler/workflow/CICD pipeline).
As an aside: I would love to see RSC become a proper thing, but only if they are a true specification that all framework builders adhere to.
My only gripe is that slowly but surely, at least at the moment, React becomes one with Next. I am a firm believer in SSR for many reasons, but a. it should be separate from the SSR meta-framework and b. it shouldn't cater to only ONE meta-framework. Now, if Remix/Astro/Qwik/Gatsby/whathaveyou support the *exact* same syntax as the Next app directory, then we could have this discussion again - plus you could make a neat video out of demo-ing it :)
preach
I think components that uses hooks and context should infer automatically "use client"
Why are you all so set on using 'use'? In my opinion "include client" would be much better since it's clear that you include it on top of the server and not one or the other.
first
Whatever gets chosen. "use client" is definitely NOT it.
useInteractions indeed