Hydration errors after updating loader-nextjs

Issues
1

Hello! We are working with the Sanity Fetcher component, and we found out some hydration errors recently. Going back on our commits we found out that it started happening after we updated our loader-nextjs from 1.0.321 to 1.0.345. We have some ssr post pages that retrieves data from Sanity, and we got this error:

image.png
image.png1806×482 67.4 KB

2

I verified that the Sanity credentials are ok, and also that the origins are allowed in the cors section

3

Also, I decided to create a fresh plasmic project to try to isolate the issue, and I got this flashing text that is the same we got on the error from our real project

Screen Shot 2023-12-06 at 11.51.36.png
Screen Shot 2023-12-06 at 11.51.36.png1234×772 47.7 KB

4

There was any change that can be causing the issue? Is there any way to avoid that flashing text? Maybe we are missing any setup?

5

This is the fresh plasmic project id: rUDnzxzitFAtRcD58qFEB7

6

Hi @nice_termite, thanks for reporting!

For the hydration error, is it possible that the Sanity Provider props are being overridden by in your code (for example, with different credentials that depend on process.ENV) and not matching the credentials data in the client?

Regarding the flash, it’s happening on this example project because it has user auth enabled, which disables SSR (but it doesn’t seem to be the case for your actual project)

7

Hi @victor,
The credentials match between my code and the client. The behavior we are seeing is: we see the SSR version (with the right data), then for a second the config error and the hydration error, and then the client version with the data (see video below).
Also I’m confused why when rolling back the loader-nextjs version to 1.0.321 on our project the issue dissapears

8

9

Hi @victor any hint/clue on this?

10

Hi @nice_termite, are you able to reproduce the hydration error in an example project?

11

Victor the primary issue we are having is that flashing valeria mentioned (screenshot and video). you can see it in the example project id she provided above

12

Hi @productive_duck, the flashing in the example project provided is not a bug and should not result in a hydration error - it happens because the example project has app authentication enabled (it shouldn’t happen if you disable app authentication). That’s because app authentication disables SSR as it might render different content per user. It doesn’t seem to be what’s happening to your actual project

13

Not sure i understand… It happens if we have auth enabled but then you say is not our case correct? Where can we see if auth is enabled or not? And how to disable it?

14

You can enable/disable it in the context menu by the project name:

image.png

15

Hi @victor, this helped me a lot to isolate the issue… I’m still a little confused but I found something. Instead of using a plasmic-init.ts file, we had a plasmic folder, and we split the init and the registration in files there. We didn’t have any issues with that until we bumped our nextjs-loader (as mentioned above).
I created a plasmic-init.ts file on the root of the project, and did the initPlasmicLoader there and the issue was solved. Also did the opposite on the clean project and I was able to finally replicate the issue. Is there any rule we were missing about not removing that file or something like that?

16

I don’t think there’s any specific rule about splitting the registration, as long as the credentials are correctly set in both client and server code… Could you share how you reproduce the issue in the clean project so I can take a look into it?

17

Sure, I created these two files under a plasmic folder:
init.ts

import { PLASMIC } from './instance.js';


export { PLASMIC };

instance.js

const nextLoaderPkg = require('@plasmicapp/loader-nextjs');
const { initPlasmicLoader } = nextLoaderPkg;

const PLASMIC_CONFIG = {
  projects: [
    {
      id: id,
      token: token,
    },
  ],
};

// export const PLASMIC = initPlasmicLoader({
exports.PLASMIC = initPlasmicLoader({
  ...PLASMIC_CONFIG,
  preview: true
});
18

thanks! I am now able to reproduce the issue. In the meantime, a workaround seems to be to use ESM instead of CommonJs when creating the PLASMIC instance - would it be possible to do in the real project?

19

So instance.js would look like:

import { initPlasmicLoader } from "@plasmicapp/loader-nextjs";

const PLASMIC_CONFIG = {
  projects: [
    {
      id: id,
      token: token,
    },
  ],
};

export const PLASMIC = initPlasmicLoader({
  ...PLASMIC_CONFIG,
  preview: true,
});