Bug: ServerSide Rendered Content is sometimes absent from the __NEXT_DATA__ hydration

[jsimondshiebing]

When loading static pages server-side the initial data returned from GQTY requests that utilize the $on notation do not return consistently. There are times where data will be visible from the source as well as in the NEXT_DATA pageProps object, however for the most part blocks return with just the __typename and name properties.

Applicable Versions

• @faustjs/core version: 0.12.4
• @faustjs/next version: 0.13.0
• WordPress version: 5.8.1

[jsimondshiebing]

Thought I'd try digging more into this and found a couple things out. We had discussed that there was potentially an issue with $on inside of an imported component and that maybe by trying to access the $on value inside of a page component may cause the server-side rendering to function as intended. Unfortunately it produces the same results (still inconsistently). I then tried calling one of our gutenberg block's fields directly in the page component, in this instance a simple WYSIWYG field on an Intro Paragraph ACF block. After a few reloads I was able to get the page to load without any data like it had been but the Intro Paragraph's WYSIWYG field did load server-side.

[blakewilson]

Thanks for reporting this @jsimondshiebing. I am seeing some inconsistencies with SSG and the $on GQty property. I'll do some debugging and report back.

[blakewilson]

I was able to reproduce this and have a minimal repo demonstrating the issue:

https://github.com/blakewilson/gqty-on-ssg-next-issue/

It seems to be related to GQty, I've opened an issue here: gqty-dev/gqty/issues/276

[jsimondshiebing]

Thanks Blake! I let our team know the status of this and will continue to monitor this issue as well as the GQty one. Thanks for setting up the repo too as a demo, if you need anything else just let me know.

[blakewilson]

This issue is actually related to having a conditional within a conditional. This is not supported by GQty. Instead, the selections have to be made before doing anything conditional with the data.

For an example, say you have a switch statement looping through block cases:

blocks.map((block, index) => {
  switch (block.name) {
    case "core/paragraph": {
      return (
        <div
          key={index}
          dangerouslySetInnerHTML={{
            __html: block?.$on.CoreParagraphBlock?.originalContent,
          }}
        />
      );
    }
  }
});

In this instance, the block?.$on.CoreParagraphBlock?.originalContent selection is called conditionally behind the switch statement. Instead, you would need to first declare the selection, then use it later in the switch statement:

blocks.map((block, index) => {
  const coreParagraphBlockContent =
    block?.$on.CoreParagraphBlock?.originalContent;

  switch (block.name) {
    case "core/paragraph": {
      return (
        <div
          key={index}
          dangerouslySetInnerHTML={{
            __html: coreParagraphBlockContent,
          }}
        />
      );
    }
  }
});

Alternatively, GQty has the prepass helper function, which allows you to manually specify fields to select, in instances like this.

[blakewilson]

More context: gqty-dev/gqty#290 (comment)

[jsimondshiebing]

@blakewilson we have made some updates to our code to match the structure above where fields are being specified outside our conditional block switch statement. Since doing that we are able to see content load in server-side consistently so that's a good sign. However it looks as though we have an issue where it's re-rendering the whole page multiple times, header and footer as well which are not handled in the switch statement conditionals, on initial load for some reason causing a flickering effect. We also tried using the prepass helper function but haven't seen a drastic difference in behavior from moving fields outside conditionals.

[blakewilson]

Hey @jsimondshiebing, awesome! I'm glad that worked.

For the flickering related issue, that sounds more like a rogue useEffect that is being called more than needed. I would confirm that there are no unnecessary useEffect statements that may be causing this re-rendering.

[blakewilson]

Hey @jsimondshiebing, wanted to follow up to see if you were able to diagnose this?

[blakewilson]

Hey @jsimondshiebing, it looks like the original issue here has been resolved, so I'll close this for now. If you experience any other problems though, please feel free to open a new issue