5 ms·
I’ve seen people make exactly this mistake with Next.js. IMO React server components is a fantastic tool for losing track of what’s exposed client side and what
by krig 2y ago
I’ve seen people make exactly this mistake with Next.js. IMO React server components is a fantastic tool for losing track of what’s exposed client side and what isn’t.
- duggan 2y agoNext.js makes you prefix env vars with NEXT_PUBLIC_ if you want them to be available client side, and Vercel has warning flags around it when you paste in those keys. It's obviously not foolproof, but it's a good effort.
- krig 2y agoThat’s env vars, but not actual variables - it’s really easy (if you are not actively context aware) to f.ex. pass a ”user” object from a server context into a client component and expose passwords etc to the client side.
- duggan 2y agoThat's a fair point! It definitely feels easier to make that mistake, and anything where context and discipline is required is a good candidate for making some horrifying blunders :)
- leerob 2y agoIf you add `import “server-only”` to the file, it will fail to compile if you to use it on the client. React also has more fine grained options where you can “taint” objects (yes that’s the real name).
- krig 2y agoYeah, the problem is that these mitigations require the developer to be context aware, ”server-only” only saves you in the positive case where you correctly tagged your sensitive code as such. The default case is to expose anything without asking. I have also seen developers simply marking everything as ”use client” because then things ”just work” and the compiler stops complaining about useState in a server context etc.