Video yükleniyor...

Video Yüklenemedi

Ana Sayfaya Dön

React Server Components allow you to call your database directly from a component. And that's great... but how do we make sure this code never ever runs on the client?

177,009 görüntüleme • 1 yıl önce •via X (Twitter)

10 Yorum

Lee Robinson profil fotoğrafı
Lee Robinson1 yıl önce

"Wait, is this a Next.js feature?" Nope — this is for usage with any React server framework.

David K 🎹 profil fotoğrafı
David K 🎹1 yıl önce

Love the video Don't love the fact that you have to install another package and opt-in to this major footgun defender

Alex Moldovan is on 🦋 profil fotoğrafı
Alex Moldovan is on 🦋1 yıl önce

This makes sense as a protection layer, but isn't it just a self-inflicted problem in the first place? Shouldn't the framework protect the developers from mistakes instead of requiring you to know this workaround?

Lee Robinson profil fotoğrafı
Lee Robinson1 yıl önce

It helps to work backwards from the ideal DX: what if you didn't have to write anything, and the framework could just magically figure everything out for you? And then look at reality. We need some sort of signal to tell the compiler the environment the code runs in. Ideally we don't want to add these checks in every single file. And ideally it wouldn't be something specific to one framework. Instead, you want a standard for the ecosystem (whether Next or other frameworks). A single line to enforce either "server-only" or "client-only". It's not auto-magical but some explicitness is a feature and not a bug. It's an adjustment though because most apps have completely separate frontend and backend words, and this model pairs well when building a "data access layer" inside of a fullstack app.

Lee Robinson profil fotoğrafı
Lee Robinson1 yıl önce

If you want to learn more, this post goes in much more detail on security in Next.js.

Dailos R. DÍAZ LARA 🦋 profil fotoğrafı
Dailos R. DÍAZ LARA 🦋1 yıl önce

IMHO a component never should call a database directly. I don’t mind if it’s a server component. Why we don’t call the database endpoint directly from a client? Cos it’s a security breach. Technology go ahead fast but it doesn’t mean that we should forget foundations.

Lee Robinson profil fotoğrafı
Lee Robinson1 yıl önce

More often, you're likely calling a "data access layer" where you co-locate your backend logic.

Daniel Nagy profil fotoğrafı
Daniel Nagy1 yıl önce

Decent workaround but importing a module to guard against code running in the wrong environment is not great.

Anthony Holmes profil fotoğrafı
Anthony Holmes1 yıl önce

This is great but now we have use client, use server, and this? I can see this being very confusing

Lee Robinson profil fotoğrafı
Lee Robinson1 yıl önce

I like the framing here personally!

Benzer Videolar

React tip: "use client" misconceptions (2/5) 🚫 "You cannot nest Server Components inside Client Components because "use client" turns everything into Client Components." ✅ We can pass the rendered result of Server Components to Client Components as props. Simple example: (Server Component) (Client Component) (Server Component) is designed for the client. It needs to instantly open and close when clicked. is designed for the server. It uses packages that don't work in the browser and needs to fetch data close to where it's stored without exposing credentials. So, how can we nest a component that uses server APIs inside a component that uses client APIs... without using `import`? React props to the rescue! --- (0:00) 1-4: Reminder: Importing code forms a module dependency graph. Adding dependencies to a server or client bundle. (0:23) 5-6: Reminder: Using components eventually forms a rendered component tree. (0:37) 9: Oh no! We get an error when trying to `import` a client API (useState) into a server module. (0:44) 10: We know the trick by now: Add "use client" to mark `2.js` as a client entry point. This moves the module to the client bundle and allows us to use client APIs like `useState.` (0:51) 11: But we get a new error! "use client" moved all imported dependencies into the client bundle, including our ORM package, which doesn't work in the browser. (0:59) 13: Let's refactor without changing our rendered component hierarchy. First, we move the `Cart` import to the parent file that imports `Modal`. This moves `Cart` outside the "use client" boundary and consequently the client bundle. (1:11) 15: Then, we pass down the rendered result of `Cart` as a prop to `Modal`. This allows `Cart` to be entirely rendered on the server as a Server Component before being passed down. `Modal` has no knowledge of what the `cart` prop is. Its only responsibility is placing whatever it receives into the `{cart}` slot. (1:15) 16: Finally, it's common to use the special `children` prop for a component's primary content. The key insight is that we were able to use props to retain our desired component hierarchy even though we changed our module dependency graph.

Delba

43,989 görüntüleme • 2 yıl önce

How should you search, filter, and paginate data with Next.js? This demo has 50,000 books in a Postgres database. • Page Load: When the page loads, we see the React Suspense fallback. This loading skeleton is displayed until the first page of books is retrieved from the database. • Searching: The search input has a 200ms debounce. After 200ms of inactivity, the form submits, updating the URL state with `?q={search}`. The Server Component reads `searchParams` and queries the database. On form submission, a React transition starts, allowing us to read the pending status with `useFormStatus` to display an inline loading state. • State Preservation: Navigating to an individual book page retains the search input state. Reloading the page or sharing the link preserves the search results. • Client-side Filtering: Filtering authors in the left sidebar is done client-side. Authors are fetched by a Server Component and passed as props to the sidebar. Changing the input value updates React state and re-renders the sidebar. • Optimistic Updates: The sidebar’s selected authors are optimistically updated with `useOptimistic`. Checkbox selections update instantly without waiting for the URL to change. • State Preservation: Navigating to an individual book page retains the sidebar filter input and selected author state across navigations, giving it an app-like feel. • Pagination: Navigating between pages updates the URL state, triggering the Server Component to query the database for the specific page of books. We also fetch the total book count to show the total number of pages. This demo isn't perfect yet (still working on it) but it's been a fun playground for some of these patterns. You can imagine a similar experience for thousands of movies, cars, products, or any other very large dataset. Demo → Code →

Lee Robinson

236,573 görüntüleme • 1 yıl önce