was out walking the dogs
will try now
@chungwu looks like that did it… have done a test deployment to stage, and no render errors so far
Thank you so much @chungwu! (just got my render-fix out)
The change we’re planning is that when you do PLASMIC.fetchComponentData(), you can now optionally pass in {target: "browser"|"server"} . It means that when you fetch the json to store into the database, you’ll have to fetch both browser and server bundles. Then when you do SSR, you should use the server bundle, and when you’re sending code to browser for hydration, you should send the client bundle. Would that work for you?
@chungwu I think so, however:
• rendered output from both browser and server versions MUST be 100% identical, else hydration fails
• I am very curious about why this is necessary… In our backend we have the same code for both, and we do checks for whether we are on SSR before doing things that should only be done on client-side…
I should be able to get this to work, just very curious about why it is necessary to have two sets of code…
Also: How can I prep for this? Will my code just start failing when you deploy this, and I’ll have to fix then, or can this be rolled out in phases, where initially code for both server and browser will run on server without issue?
Shouldn’t be breaking – you can switch over to this whenever you’re ready. There’s also no hurry.
That’s right – browser/server versions will output the same HTML 
The reason is that some of our components from the component store uses npm packages that must be built either targeting the browser or the server (for example, isomorphic-fetch). So we end up producing two separate bundles, instead of keeping both server and browser code and switching at run time.
got it… we definitely want to keep client-side code to a minimum
just give me a heads-up when this goes live so I can start implementing!
@chungwu thanks for great support on this!