Last week, I had a live streamed conversation with Joe Savona and Dan Abramov.
I’ve had many questions and concerns about React Server Components and Dan and
Joe were kind enough to give me some time on a live stream to ask about them.
I used summarize.tech to generate this summary of our
live stream. I suggest watching the whole thing if you’d really like to dive
deeper!
It should be noted that the objective of this live stream was not to instruct
you, but to answer my own questions. I realize some folks will wish we spent
more time explaining some of the concepts and answering other people’s
questions, but we only had time for my own questions. This is also why there
was such a big focus on Remix as well since I’m a heavy Remix user.
00:00:00 – 01:00:00
React Server Components are a solution to having all components on the server
and sending their results to the client, allowing any number of components to be
used on a page regardless of its size. They have automatic bundle splitting,
where unused components are not included in the page, making it an optimal
architecture. However, it is essential to understand that this is not the
primary problem that server components solve, and the pitch should depend on the
audience’s needs. React Server Components expand the React model, allowing each
component to fetch the data it needs, reducing the amount of client-side
components. The architecture presents benefits, such as co-locating data
dependencies and writing code in a request response model, and can use both the
server and client. To avoid waterfall issues, the speakers suggest putting SSR
on the edge and server components close to the data layer. The speakers also
discuss the trade-offs of RSC, including the n plus one problem, which can be
solved with other solutions like Remix. They also discuss the runtime
characteristics of React Server Components, such as deduping and overloading
standards, and how frameworks like Next.js can improve potential duplication of
data in server-side rendering. The consensus is that Next.js and Remix both
provide similar ways of accessing request and response objects. Finally, the
speakers discuss the use of streaming as the default behavior and the importance
of coordinating fetches to decide what to do with multiple loadings.
- 00:00:00 In this
section, Kent C Dodds introduces the topic of React server components and the
guests on the stream, Joseph Savona and Dan Abramov. Kent has been following
the progress with suspense and server components and has been using remix for
the last two and a half years. He struggled to understand the benefits of
server components initially. However, he feels that he now has a good idea of
how they solve the problems that other solutions like CMS cannot, and the
guest speakers will correct his misunderstandings. The purpose of the stream
is to discuss the use cases and benefits of React server components. - 00:05:00 In this
section, the team discusses the use case of React server components, primarily
formulating the idea that the solution to the problem lies in having all the
components on the server and sending their result to the client, so that any
number of components can be used on a page, regardless of its size.
Additionally, server components have automatic bundle splitting, where if a
page does not use some of the components that are sent to the client, they are
not included, making it a beneficial architecture to optimize. While the
architecture presents many optimizations and benefits, the team clarifies that
it is vital to understand that this is not the main problem that server
components are solving, and the pitch should be dependent on the audience’s
needs, be it for single-page apps or multi-page apps. - 00:10:00 In this
section, the speakers discuss the differences between React Server Components
and other frameworks, such as Remix and Astro, and highlight how React Server
Components expands the React model. They explain that with server components,
each component can fetch the data it needs, allowing for co-location of data
dependencies and reducing the amount of client-side components needed.
Additionally, when navigating with React Server Components, state is retained,
making for a more cohesive experience. They also discuss the potential for
reusable components, like a tweet component that can pull data from the
Twitter API, to be shared via npm. - 00:15:00 In this
section, the speakers discuss the benefits and use cases of server components,
such as writing code in a request response model and having the ability to
fully use the server and the client. They also note that while remix offers
some of these features, server components provide more flexibility in
composing server code. However, the speakers acknowledge that server
components can cause waterfall issues and may require manual preloading to
avoid them. They suggest putting SSR on the edge and server components closer
to the data layer to minimize latency. - 00:20:00 In this
section, the speakers discuss the challenges of server rendering with server
components and Remix. They mention the importance of doing everything in a
single query and how pushing data to the edge can help mitigate some of the
issues. The speakers also talk about the difficulties of writing JavaScript to
avoid triggering waterfalls and how Remix and server components each have
their own unique approaches to handling the problem. They also clarify that
route segments can be fetched in parallel with Remix, much like server
components. Additionally, they explain that server components may see
performance problems if they don’t do parallel data load for route segments
but argue that waterfalls may not be the root problem in these cases. - 00:25:00 In this
section, the speakers discuss the potential problem of the n plus one problem
when rendering a list with multiple child items, which can cause unnecessary
data loading and make the system slow. They suggest two common solutions to
this problem – using the data loader pattern to batch up queries or cashing
the data – and emphasize the importance of observability to detect performance
problems. Additionally, they clarify that waterfall problems may occur even in
parallel execution, since it depends on the system’s capacity to handle those
parallel queries. - 00:30:00 In this
section, the speakers discuss the benefits of co-locating data dependencies
with components and how server components can address this. They explain that
this approach has been attempted for years, but it wasn’t until GraphQL and
Relay that it was executed successfully. However, GraphQL is not the right fit
for every application, and server components take the best ideas from GraphQL
and Relay and allow developers to co-locate data dependencies with components.
This creates a scalable structure for writing applications while effectively
removing the co-dependency on the server. The speakers go further to explain
how RSC presents several trade-offs, including the N+1 problem, which can be
avoided with other solutions like Remix. - 00:35:00 In this
section, the discussion is on the use of server components and whether they
can solve the problem of duplicated fetches when rendering components that
make requests. The speakers argue that while server components can deduplicate
fetch requests when rendering the same component multiple times, it is not the
way things should be done in a remix app. In a remix or next app, the fetch
request should be made at the route layer or in a layout, so it only happens
once and is passed as props. They discuss a scenario where it is necessary to
make the same fetch request multiple times for each component instance. The
speakers differ in their opinions, with one arguing that server components do
not completely solve this problem, while the other argues that this kind of
problem should not exist in a remix app. - 00:40:00 In this
section, the speakers discuss the runtime characteristics of React Server
Components and clarify that it is not slower than the client counterpart,
especially since the deduping problem is already solved. They also touch on
the potential issue of overloading standards and not using standards in some
situations, such as overloading fetch to dedupe automatically. The speakers
point out that React does not patch fetch, and the plan is to provide its own
version that works with identification and hydration. However, they suggest
that frameworks may need to patch fetch if necessary. Additionally, the
section discusses the mechanism of deduping to ensure that it only happens
within a specific user’s request and not across multiple users. React Server
Components provide an async context that allows for this per-request deduping. - 00:45:00 In this
section, the speakers discuss how frameworks like Next.js can improve upon the
potential duplication of data in server-side rendering. Next.js, for example,
offers options like cash keys to specify whether data is static and can be
shared between users, or if it should be built during the build process.
Server components also have the ability to create payloads that let users
navigate without losing state, and these payloads can be cached if a fetch
option is specified. Additionally, the speakers touch on accessing
request-specific data like cookies and cache headers from a server component.
While this is framework-specific, Next.js offers an import function for
accessing cookies directly. The idea of importing data like this is still
considered non-standard, as many developers prefer working with the request
object directly. - 00:50:00 In this
section, the focus is on accessing request and response objects. The consensus
is that Next.js and Remix both provide similar ways of doing so by skipping
unnecessary steps through utility functions. However, in Remix, there’s an
‘expert current get request function’ that makes it easy to access the
underlying request object. Regarding response objects, it largely depends on
how they are set up in the framework. In Remix, since the loaders are called
before the stream starts rendering, fetch headers can be set to control
caching behaviours accordingly. - 00:55:00 In this
section, the participants discuss the use of streaming as the default behavior
in React server components. They mention that streaming implies that every
component is like an implicitly deferred loader, but if someone is using defer
in remix, that ability is lost. They also discuss how in a server components
world, the focus is on streaming and getting stuff out of the request, and the
core question is how to get stuff into the response from a server component.
Nevertheless, there is some controversy around this issue since different
fetches can have different headers, so a system that coordinates them and
decides what to do with several loadings is necessary.
01:00:00 – 01:40:00
In this YouTube video, Dan Abramov, Joe Savona, and Kent C. Dodds discuss the
workings and benefits of React Server Components (RSC). They explore the idea of
a pluggable and customizable framework for caching and discuss the benefits of
breaking components down into smaller pieces. The speakers also talk about the
separation of server and client code and how it benefits developers. Another
topic they cover is the limitations of interacting with databases in server
files and how mutations can solve some performance problems. The speakers
emphasize the mental model shift required for working with RSC and discuss the
role of client components. They also highlight the benefits of co-location and
granular trade-offs on the component level. They recommend checking out the
documentation and the implementation of RSC in Next.js 13 for those interested
in trying it out. The speakers also discuss the potential benefits of RSC for
users on either the technical or client-side and express excitement about the
upcoming documentation release.
- 01:00:00 In this
section, the speakers discuss the idea of caching and how it relates to React
Server Components. They explore the possibility of a pluggable and
customizable framework that could automatically combine fetch instrument data
and decide what the right thing is for caching. There is a focus on the
importance of caching and how server components architecture can cache output
itself, rather than just reducing the cache fund for the client. The speakers
also touch on the topic of breaking components down into smaller pieces, which
is becoming more commonplace with hooks, suspense boundaries, error
boundaries, and server components. There is a discussion about the trade-offs
of breaking components down into smaller pieces and how it relates to the
learning aspect and ergonomics of React. - 01:05:00 In this
section, the speakers discuss the trade-offs of using separate files for
server and client code in React Server Components (RSC). While some may prefer
the ability to interleave code, using separate files helps prevent mistakes
such as exposing secrets meant for the server to the client. One speaker notes
that while the separation of files may be seen as a limitation of RSC, it’s
not a fundamental limitation, and RSC is not prescriptive about how to
structure your app. Overall, the decision to separate files for server and
client code is seen as a good trade-off for the benefits it provides,
including better developer experience and helping prevent mistakes. - 01:10:00 In this
section, the speakers discuss the limitations of interacting with databases in
server files and the clunkiness of adding event handlers for interactions.
They mention Remix ahead in this regard with its nice Progressive Enhancement
story with forms and handlers, and how the team is working on mutations to
allow one to pass functions from the server to the client in a product
integration, allowing behavior change with a network boundary automatically
integrated without having to add it for every interaction. The speakers go on
to say that restructuring the apps in the future with the use of server
components will bring about different ways of creating new apps. - 01:15:00 In this
section, the speakers discuss how mutations are essential to building modern
applications and how the lack of them in Remix caused issues for its paid
website. They also touch upon how the structure of server components is still
unclear, but it’s crucial to solidify patterns so that it becomes the norm for
developers. Additionally, the metaphor of bone and muscle is discussed, which
helps in understanding where server components fit and how they serve as an
optimization, avoiding the need to run a lot of code on the client to connect
with the server. - 01:20:00 In this
section, the speakers discuss the mental model shift required for working with
React Server Components. The concept of treating Server Components as a
skeleton to be fleshed out with client-side interactivity is explored, where
the interactive parts have holes that the parent component fills in. This
approach is compared to the traditional method of thinking about React apps as
an entire tree. They go on to explain the practical application of this
approach, including how it can solve some performance problems and make props
plumbing easier. - 01:25:00 In this
section, the speakers discussed the goal of an app using server components and
the role of the client components. The aim is to have the server components go
as deep into the tree as possible, while the client component accepts slots
that can further the depth of the server components when there’s
interactivity. However, mutations need to be fully established before
exploring this direction. Client components are still vital, and some client
components can be better than server components, such as in situations where
server components generate bloated HTML for lengthy pages, making the overhead
not worth it. - 01:30:00 In this
section, the speakers discuss the benefits of server components, with
co-location being a major one. The ability to write a single technology,
language, framework and set of idioms across client and server makes it easier
to bring composability to the server. The speakers highlight an example of a
code highlighter component that could be a server component rendering a client
component. They also highlight how this approach allows for granular
trade-offs on the component level, with no need to change the API of
components or load parsers on the client. - 01:35:00 In this
section, Dan Abramov and Joe Savona discuss how the optimizations of React
Server Components naturally fall out of the componentization and npm
integration of the code, which is exciting for developers. They recommend
checking out the new docs site and the original presentation for a conceptual
model of server components. For those who want to dive into the code, they
suggest looking at Next.js 13 app router since it has the most comprehensive
implementation of server components. While they are currently working with
bundlers such as The Parcel Bundler and Webpack Plugin, they hope to see React
Server Components become a first-class feature in other libraries as well. - 01:40:00 In this
section, the speakers discuss the separation between React Server Components
and how it can benefit different users on either the technical or client-side.
They direct users to check out the RFC that Joe wrote, which details how the
components work and the benefits that can be obtained from them. Additionally,
they mentioned that the plan is to upstream the React components into the
React documentation while considering the balance between explaining these
components with or without frameworks. The speakers conclude by thanking the
host and expressing excitement for the upcoming documentation release and the
opportunity to see the server component stocks published.
I hope the discussion was helpful to you!
Source link
