Content pfp
Content
@
0 reply
0 recast
2 reactions

Brenner @ Edge City pfp
Brenner @ Edge City
@brenner.eth
Ok who wants to help me understand nextjs app router? And ‘use client’ vs ‘server-only’? I’m not used to not being able to have any “useState()” functions wherever I want??
10 replies
9 recasts
56 reactions

​woj pfp
​woj
@woj.eth
sever is the default execution environment now but its totally fine not to use it if you dont want to use it just add 'use client' and you can use hooks again one you do use client, all downstream components will be rendered on client side too
1 reply
3 recasts
29 reactions

dylan pfp
dylan
@dylsteck.eth
going to try my best to explain this in one cast(as someone who's read about RSCs but hasn't used them much lol) client-side code needs to be marked as 'use client' -- client code can run in server code files, but not the other way around server-only code makes the function itself async, so you can mutate data & return UI with that data eg. your client-side code could be static info like a navbar and then instead of blocking while waiting for your API request, the server can load the data and ui together
1 reply
0 recast
4 reactions

iSpeakNerd 🧙‍♂️ pfp
iSpeakNerd 🧙‍♂️
@ispeaknerd.eth
Also diving into nextjs currently 🤝
0 reply
0 recast
1 reaction

Tayyab - d/acc pfp
Tayyab - d/acc
@tayyab
What Woj said, server is the default execution environment. Use server for any rendering, and client for interactions. Create client components inside of server components where you need the interaction. We dropped tRPC and use server actions, but I think there are deeper architectural details before I’d recommend that.
0 reply
0 recast
1 reaction

Tayyab - d/acc pfp
Tayyab - d/acc
@tayyab
👋🏾
1 reply
0 recast
0 reaction

Tayyab - d/acc pfp
Tayyab - d/acc
@tayyab
Also, this fucked me up for quite some time before I had someone smarter than me explain and show me working code.
0 reply
0 recast
1 reaction

Doug Alcantara pfp
Doug Alcantara
@snuglas.eth
we learned a lot while migrating @hypersub to the app router (from Next 12, where we initially began dev on it). ideally, the `use client` boundary should be as far “down” the tree as you can get it. if you can identify/distill client components down to their interactive elements, and use server components for server things “higher up”, I think that’s a sign you’re moving in the right direction. router.refresh will trigger re-fetch/re-render on server components as well. requires a change to the mental model, certainly.
0 reply
0 recast
0 reaction

NATALIΞ pfp
NATALIΞ
@rootcause
Pro-tip: make a client-side ContentWrapper component that goes in your layout file around {children}. Now you have a place to put all your providers and top level hooks. I just saved you countless development hours.
0 reply
0 recast
0 reaction

Cardman 🔷 pfp
Cardman 🔷
@therealcardman
if you are building a "logged in" app you'll probably need 'use client' just about everywhere. but the server thing helps if you have a lot of logged out pages and improves performance
0 reply
0 recast
0 reaction

ProddleroSingarl pfp
ProddleroSingarl
@proddlerosingarl
Next.js app router is confusing with 'use client' vs 'server-only' and limitations on useState().
0 reply
0 recast
0 reaction