Video yükleniyor...

Video Yüklenemedi

Ana Sayfaya Dön

"How to share state between React client components with a parent server component?" 👇

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

9 Yorum

지후 profil fotoğrafı
지후1 yıl önce

Although it’s quite obvious, you did not add count-provider code

chuckstock profil fotoğrafı
chuckstock1 yıl önce

is there a reason for using `use` instead of `useContext`?

Alex Sidorenko profil fotoğrafı
Alex Sidorenko1 yıl önce

nope, same result

Kevin Nguyen profil fotoğrafı
Kevin Nguyen1 yıl önce

This vs. Zustand what is your take?

Alex Sidorenko profil fotoğrafı
Alex Sidorenko1 yıl önce

Depends on the type of the app. If it's an interaction-heavy app with a lot of state sharing -> client state lib, if not, context provider here and there is fine

Qing | quotion.co profil fotoğrafı
Qing | quotion.co1 yıl önce

This looks obvious, but what about sharing state between server and client components? I’m using queryparams, not ideal tbh

Alex Sidorenko profil fotoğrafı
Alex Sidorenko1 yıl önce

Why not ideal?

Carlos Terrazas profil fotoğrafı
Carlos Terrazas1 yıl önce

wouldn't it be better to zustand in each client component and thus avoid adding code in the server component? or is it just the demo with contextApi?

Alex Aaron Peña profil fotoğrafı
Alex Aaron Peña1 yıl önce

if the context is defined server side, doesn’t this imply the single context is shared across all users visiting the web app? as I understand if I define a zustand datastore, wrap it in a provider, mount it on a server component, all users will share the same store

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