Love the new paradigm. But would really prefer defining server/client components at the filename level: e.g. Modal.client.tsx, NewsStory.server.tsx. "use" string directives just feel out of sync on how we write JavaScript
it doesn't make it totally server because you can attach js events on the components that makes them "universal" so there should be signals to make it fn level. but I agree that sensible defaults are the way to go
Love your talk. We used to have allergic reactions from people seeing html inside js, and css inside js, not anymore. I always tell people stop breaking code up by their types, but their functionality. Nobody writes button without styles, and nobody writes button without its corresponding js or form actions. If then, why are we breaking up the code into different files? That is a code smell and its called fragmentation. If we have a button that adds todo list (handled on the server), this button is useless without server action, then why not put them together in the same component? The only reason why we didn't do it before was because there just wasn't a good way to do it.
Looks like "good" old PHP :) let's mix SQL and HTML together... The presentation looks good, and the new tutorial too... But my feelings are quite contradictory until I've tested that by myself. Especially I am curious about some complex applications and how this thing will be tested.
Can you unit test React Server Components, or would they only be tested via E2E tests? It's easy to test client components based on useSWR, because I can mount the component and mock out its network API calls to create any scenario my test needs.
I wonder about security implications of third party packages. What if a from npm has a formAction in it that steals my server creds/data. How would I even track it and stop such an attack?
@@VercelHQ thanks. However this only let's you protect your own server actions and components. How can I stop a random from npm performing certain server actions?
What is preventing you from downloading a normal NPM package that steals your creds today? I dont think server actions leave you anymore exposed to supply chain attacks.
@@grunklejp I completely agree. Even today I can import a design system component and SSR it and end up running third party code during the server pass. I guess I'm feeling bit nervous/lack of control over what a third party component can end up doing without my knowledge. If components can contain both server and client code, it makes them even more powerful than before for attacks as well Maybe Next can add an opt-in system where we can allow formAction or action on form components only for selected npm packages.
I understand the sentiment but couldnt we make formAction "use server" by default? seems like too much to write again "use server" inside a server component
A glimpse into React's origins: It wasn't designed for data handling or retrieval. Instead, React aimed to refine UI creation with one-way data binding, ensuring a seamless rendering flow. Overengineering is the bane of elegant programming.
@@JakeLuden React was created to simplify UI development. Adding other concerns doesn't improve it, it makes things worse by introducing a bunch of decisions and compromises. The result is easy to predict
![ผัวเถื่อน - ยูริ โตเกียวมิวสิค [ OFFICIAL MUSIC VIDEO ]](http://i.ytimg.com/vi/P08ORRVDGl8/mqdefault.jpg)
Love the new paradigm.
But would really prefer defining server/client components at the filename level: e.g. Modal.client.tsx, NewsStory.server.tsx.
"use" string directives just feel out of sync on how we write JavaScript
it doesn't make it totally server because you can attach js events on the components that makes them "universal" so there should be signals to make it fn level. but I agree that sensible defaults are the way to go
this is the best argument so far
PHP is best language in the word
Love your talk.
We used to have allergic reactions from people seeing html inside js, and css inside js, not anymore.
I always tell people stop breaking code up by their types, but their functionality.
Nobody writes button without styles, and nobody writes button without its corresponding js or form actions.
If then, why are we breaking up the code into different files? That is a code smell and its called fragmentation.
If we have a button that adds todo list (handled on the server), this button is useless without server action, then why not put them together in the same component? The only reason why we didn't do it before was because there just wasn't a good way to do it.
They guy at the bottom right was watching memes 👀
Sam delivering the best presentation as usual!
that's a lot of technology and innovation for a basic to-do spa 😂
here comes the meme attack
Loved this presentation; just what I needed amidst all these new and shiny updates to build a mental model.
Looks like "good" old PHP :) let's mix SQL and HTML together... The presentation looks good, and the new tutorial too... But my feelings are quite contradictory until I've tested that by myself. Especially I am curious about some complex applications and how this thing will be tested.
Yes , after I saw the server component, i though , react is a lego. I feel like a lego owner who press a lego in night. Thanks you killed SoC.
Can you unit test React Server Components, or would they only be tested via E2E tests? It's easy to test client components based on useSWR, because I can mount the component and mock out its network API calls to create any scenario my test needs.
great talk!!
can we get the github repo link?
Nice presentation
First commit -m
I wonder about security implications of third party packages. What if a from npm has a formAction in it that steals my server creds/data. How would I even track it and stop such an attack?
nextjs.org/blog/security-nextjs-server-components-actions
@@VercelHQ thanks. However this only let's you protect your own server actions and components. How can I stop a random from npm performing certain server actions?
@@DivjotSingh I think if you taint your creds it shouldn't creep out but no one's stopping from leaking non tainted data
What is preventing you from downloading a normal NPM package that steals your creds today? I dont think server actions leave you anymore exposed to supply chain attacks.
@@grunklejp I completely agree. Even today I can import a design system component and SSR it and end up running third party code during the server pass.
I guess I'm feeling bit nervous/lack of control over what a third party component can end up doing without my knowledge. If components can contain both server and client code, it makes them even more powerful than before for attacks as well
Maybe Next can add an opt-in system where we can allow formAction or action on form components only for selected npm packages.
I understand the sentiment but couldnt we make formAction "use server" by default? seems like too much to write again "use server" inside a server component
Form action doesn't have to be inside a server component, it could be in client too
it's literally 2 words lmao
A glimpse into React's origins:
It wasn't designed for data handling or retrieval.
Instead, React aimed to refine UI creation with one-way data binding, ensuring a seamless rendering flow.
Overengineering is the bane of elegant programming.
It’s not over-engineering, it’s just 2023. React’s origins solved 2013 problems. Next is helping solve 2023 problems.
@@JakeLuden
React was created to simplify UI development. Adding other concerns doesn't improve it, it makes things worse by introducing a bunch of decisions and compromises. The result is easy to predict
@@JakeLudenThose 'problems' already existed before 2023 but were (intentionally or not) unreachable by the React ecosystem.
15:44 🤯 I have 🫘 using SERVER ACTIONS, but I have 💭 that there 😯 only for from submissions. That is, a ‘’ with a ‘“submit”’ button.