#Collocating server-client side code in modules and imports

12 messages · Page 1 of 1 (latest)

fresh delta
#

In next 13, client side component or hooks cannot be imported by RSC and modules can be made server only to avoid client components poisoning...

Before next 13, I used to group some of my code by domain/subject in folders and create an index.ts file to expose clearly what I want to be used.
Now, if I do the same, the module will be unusable in both RSC and CSC (because of poisoning guards)...

I manage to get around this until now by adding a sub folder named server with it's own index.ts file to keep client and server code isolated but I'm not sure about this pattern?
I imagine that this could be easily solved if we could conditional import what we want in index.ts based on runtime type... I'm not sure it's feasible.

Did anyone come with another solution to organize code in next 13?

#

Collocating server-client side code in modules and imports

keen vault
#

explored that space a bit because I come from Meteor

#

it's probably possible by hacking webpack, the thing is that in next.config.js you may notice that it runs twice, once for client once for server, so you can tweak the webpack config differently in this scenario eg to favour index.server over index.client

#

but my 2 cents: don't do that, just be explicit about your files

#

put server code in /server folder, client code in /client folder, shared code in /shared folder

#

or use index.server / index.client / index for simpler use cases

#

and import the right one in the right context, there are enough safeguards against poisoning to protect you

#

my idea was to rely more on linting rule, that's a great place to do those check if you want additional security, adding a new Eslint local package is not that hard, you can most probably detect imports and parse the content

#

Next 13 or 12 doesn't change anything this is issue is as old as full-stack development

fresh delta
#

Ok, interesting. I didn't really know if isolation was the right things to do but at the same time, I noticed that I have to know before hand which runtime type is a function and that's frequently not clear.