Skip to content

Commit 65c4874

Browse files
committed
start rscs
1 parent c3d6fdf commit 65c4874

File tree

7 files changed

+55
-30
lines changed

7 files changed

+55
-30
lines changed

lessons/02-react-render-modes/A-client-side-react.md

Lines changed: 1 addition & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -16,14 +16,6 @@ This is how we've written React for a very long time (10+ years now) and will co
1616

1717
Brian's (not-so) 🔥 Take: this is the default way you should write React. Everything is a contextual performance enhancement, and should only be reached for when: 1. the performance enhancement actually meaningfully helps (it frequently doesn't) and 2. you actually have a need for the performance enhancement (you frequently don't). This style of rendering yields the simplest apps that are easiest to write, easiest to maintain, and easiest to debug.
1818

19-
# TODO Move these two to their own pages
20-
21-
## Server-Side Rendered (SSR)
22-
23-
This is a hybrid of the two. Essentially here on inital page load, your server will handle the initial rendering of the React app and ship rendered HTML. The full bundle of the React component will then be shipped to the client and React will "hydrate" the markup. Hydrate in this case just means it'll take the inert HTML and add anything interactive to it. In a sense, the React app "takes over".
24-
25-
SSR is a double-edged sword. It can be a huge help, saving slow devices from having to run big React apps and shaving off precious milliseconds of _time to first paint_ (but _not time to first interactive_). So as you can see, it's a tradeoff, and frequently SSR can actually make things worse, not better, so do be careful. Measure your key metrics and make sure it's helping!
26-
27-
## React Server Components
19+
We're not going to write a client-side React app today – [Complete Intro to React][v9] covers that in-depth. So let's move on to writing SSG and SSR apps.
2820

2921
[v9]: https://react-v9.holt.courses
Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
We've talked about client-side React apps (no server), static site generation apps (server runs only at compile time), and server-side rendered app (server renders initial page but then client does the rest). Now we're going to talk about react server components which involves the server even more.
2+
3+
## What are RSCs?
4+
5+
RSCs are not SSR 2.0.
6+
7+
This is a common misconception that I just want to dispel upfront: these things are relatively unrelated in the sense you can SSR without RSCs, RSCs without SSR, both, or neither!
8+
9+
RSCs introduce the notion of a server to an ongoing React app. Whereas SSR renders the page once and then is no longer involved in the ongoing React app, RSCs introduce the notion that the server continues to render parts of the app. An RSC is a component that only renders on the server and sends its complete markup to the app – the client-side app doesn't even have the code to render the component client-side - it can only receive markup from a server and then insert that into the app.
10+
11+
> A React server component is a component that _only_ renders on the server.
12+
13+
Why is this useful? For a couple of reasons. No matter how much of an interactive app you have, large swaths of it are inert markup, text, and content. You don't need React to generate HTML that shows a few headers and paragraphs. We do it because it's simpler to keep all the code together, but the truth of it is just that: in the grand scheme of things, React is really only needed client-side to add interactivity to an app. Everything else is developer experience and code organization.
14+
15+
Enter RSCs. For one, they're just a simple rendering of a page's content, rendered once, on the server. This means that it doesn't matter how powerful a user's device is, the rendering is happening on the server. It also means users aren't receiving the code for pages they aren't going to visit, so the bundle can be split pretty well.
16+
17+
But the biggest, most powerful feature (in my opinion) is that RSCs can use modules that can only be used on the server. Let's say you're making a messaging app (like we're about to): that data all has to be stored in a database somewhere. Normally you'd need a React app fetch that data with a get request, but with RSCs you can just make the request directly in the React component 🤯
18+
19+
All the secret connection strings you need to have to access your database? Never leave your server! It makes writing React components that read & write from databases, private APIs (like OpenAI, etc.), or need other server-side components very fluent to write. We're about to see how.
20+
21+
## Okay so don't write RSCs by hand
22+
23+
But we're going to lol.
24+
25+
RSCs are really meant to be written by frameworks and _not_ be written by the masses. It's a pretty deep integration to build with your bundler (and they only ship Webpack at the moment) and it's very hard to get right and not get a net-negative on performance.
26+
27+
It's also just a lot of code to write, and there already a few frameworks out there that will do it better than you likely have time to.
28+
29+
- [Next.js][next]
30+
- [React Router v7 / Remix][remix] (soon)
31+
- [TanStack Start][tanstack] (soon)
32+
33+
Next.js works with RSCs today, as of the writing of this course, and embraces the full surface capabilities of RSCs. React Router v7 and TanStack Start both have expressed that at least initially they will be selective of which features that they embrace that make sense with their frameworks (and I support that! No reason to shoehorn it in.)
34+
35+
We'll end up writing a whole app in Next.js by the end of the course, but we're going to start with doing it by hand!
36+
37+
## NotePasser
38+
39+
Remember in school when you would pass notes by hand? No? Well, back in my day (_shakes fist at passing cloud_) we didn't have cell phones and had to rely penmanship and steathily trying to pass a paper note to our friend in class.
40+
41+
We're going to build an app inspired by that today, where we can pass notes from one user to another.
42+
43+
One note - I had originally built this app to have a full on auth provider, but realized it was adding a lot of complexity to the app that wasn't teaching you how to do React. Instead this app is going to sort of fake auth. We're just going to assume whoever is using the app is always user ID `1`. This is done in the name of simplicity so we can just focus on building React apps, but feel free to later to add a cool auth provider like [Neon Auth][neon] (I helped build this one!!), [Clerk][clerk], [Descope][descope], or any other of your favorites.
44+
45+
[next]: https://nextjs.org/
46+
[remix]: https://reactrouter.com/
47+
[tanstack]: https://tanstack.com/start/latest
48+
[neon]: https://neon.tech/
49+
[clerk]: https://clerk.com/
50+
[descope]: https://www.descope.com/
Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
{
2+
"title": "RSCs without a Framework",
3+
"icon": "file-code"
4+
}

lessons/03-thoughts-on-js-and-css/A-css.md

Lines changed: 0 additions & 6 deletions
This file was deleted.

lessons/03-thoughts-on-js-and-css/B-javascript.md

Lines changed: 0 additions & 5 deletions
This file was deleted.

lessons/03-thoughts-on-js-and-css/C-npm.md

Lines changed: 0 additions & 6 deletions
This file was deleted.

lessons/03-thoughts-on-js-and-css/meta.json

Lines changed: 0 additions & 4 deletions
This file was deleted.

0 commit comments

Comments
 (0)