Code reusability across client-only and server-only
Unanswered
matchai posted this in #help-forum
matchaiOP
Hey folks! 
I've got a quick question and would love a hand.
I've been building with the idea of using RSC whenever possible. I've got plenty of utils that function similarly across both client and server (e.g.
More and more, I'm wanting to build out more complex functions that reference multiple bits of differently-stored state: auth state, router state, tenant state, theme state, etc.
It seems like my options are:
1. Create server and client versions of the functions, which source data differently, but crunch the data the same way.
2. Create common utils to be used by server and client, but each require all my various bits of retrieved state to be passed as arguments.
No. 1 doubles up the code I have to maintain, which wouldn't be as fiddly if I could keep both implementations in the same file. Alas, I can't have the client and server code in the same file.
No. 2 requires me to juggle variables, which are effectively global in both environments.
Have I overlooked a good way to manage both?
Should I just relent and use client components for code maintainability?
Any tips would be appreciated
I've got a quick question and would love a hand.
I've been building with the idea of using RSC whenever possible. I've got plenty of utils that function similarly across both client and server (e.g.
getAuth vs useAuth), one using headers/cookies, and the other using context.More and more, I'm wanting to build out more complex functions that reference multiple bits of differently-stored state: auth state, router state, tenant state, theme state, etc.
It seems like my options are:
1. Create server and client versions of the functions, which source data differently, but crunch the data the same way.
2. Create common utils to be used by server and client, but each require all my various bits of retrieved state to be passed as arguments.
No. 1 doubles up the code I have to maintain, which wouldn't be as fiddly if I could keep both implementations in the same file. Alas, I can't have the client and server code in the same file.
No. 2 requires me to juggle variables, which are effectively global in both environments.
Have I overlooked a good way to manage both?
Should I just relent and use client components for code maintainability?
Any tips would be appreciated
6 Replies
i think the point of server rendering is that you can minimize client things (ie
useAuth)also i don't see why you can't abstract it out as much as possible to a file that both contexts import
@riský i think the point of server rendering is that you can minimize client things (ie `useAuth`)
matchaiOP
While I agree with the case for auth, unfortunately, I can't quite avoid having
The trouble is that the file with the context would need to be
theme in both client and server without it needing to be passed to every component.The trouble is that the file with the context would need to be
use client to function, so functions from that file can't then be imported and used in server components.if the file isn't a use client, it can be imported into a client or not... (but it will be client if imported into one)
@riský if the file isn't a use client, it can be imported into a client or not... (but it will be client if imported into one)
matchaiOP
Ah, I misunderstood what you meant by “contextsâ€. Yep, that’s what I’ve done.
One function split into three files, effectively: common, server, and client.
Cumbersome but it works. Just checking that there’s no other “blessed†solution
One function split into three files, effectively: common, server, and client.
Cumbersome but it works. Just checking that there’s no other “blessed†solution
imo you should be able to do it and make it not too chaotic