How Next.js is delivering React’s vision for the future (Sam Selikoff)

Presented at Next.js Conf 2023.
View all talks from the conference: • Next.js Conf 2023 - In...
Explore templates of sites built with Next.js: vercel.fyi/verceltemplates
Check out the Vercel product tour: vercel.fyi/producttour
Server Components have brought React closer to fulfilling its mission of giving developers a unified paradigm for building rich user interfaces. This talk will explain how RSC, which started out as the official answer for how to fetch data in React, led to an evolution of the React paradigm that brings the composability of components across the network boundary. We’ll first look at how RSC in Next.js improves upon the previous generation of data-fetching solutions (like getServerSideProps and SWR), why RSC is about so much more than data fetching, and end with an exploration of how this new paradigm will make even the non-UI parts of our applications easier to build in the future.

[@jordantan888]

this is the best argument so far

[@dawid_dahl]

Loved this presentation; just what I needed amidst all these new and shiny updates to build a mental model.

[@zalodias]

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

[@viniciusataidedealbuquerqu2837]

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

[@rockNbrain]

great talk!!

[@voinbobar]

Sam delivering the best presentation as usual!

[@dinuka]

Nice presentation

[@benme1386]

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.

[@bosung90]

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.

[@jmula1963]

can we get the github repo link?

[@DivjotSingh]

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]

nextjs.org/blog/security-nextjs-server-components-actions

[@DivjotSingh]

@@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?

[@viniciusataidedealbuquerqu2837]

@@DivjotSingh I think if you taint your creds it shouldn't creep out but no one's stopping from leaking non tainted data

[@jpkiser5051]

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.

[@DivjotSingh]

​​@@jpkiser5051 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.

[@viniciusataidedealbuquerqu2837]

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

[@TheTmLev]

Form action doesn't have to be inside a server component, it could be in client too

[@jijieats]

it's literally 2 words lmao

[@janstrnadek1441]

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.

[@alansaldivares]

They guy at the bottom right was watching memes 👀

[@yipansong2688]

PHP is best language in the word

[@hamzadata]

here comes the meme attack

[@MahmutGundogdu]

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.

[@solarspear27]

First commit -m

[@codefinity]

15:44 🤯 I have 🫘 using SERVER ACTIONS, but I have 💭 that there 😯 only for from submissions. That is, a ‘’ with a ‘“submit”’ button.

[@catalinim4227]

that's a lot of technology and innovation for a basic to-do spa 😂

[@pbritotube]

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]

It’s not over-engineering, it’s just 2023. React’s origins solved 2013 problems. Next is helping solve 2023 problems.

[@pbritotube]

​@@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

[@youreale]

@@JakeLudenThose 'problems' already existed before 2023 but were (intentionally or not) unreachable by the React ecosystem.