SSR only works when template query is present

[rrmesquita]

Description

When a template component doesn't have a query property, the SSR for that page simply doesn't work.

It looks like a bug to me because it doesn't make sense – if a page doesn't require remote data, there's no reason not to generate it statically.

In my reproduction example, I added a query to fetch some unused piece of data, just to show that the sole presence of a query triggers the SSR.

Steps to reproduce

1. Clone my reproduction repository
2. Install dependencies, run the build then npm run start to start the server
3. In the browser, navigate to /sample-page
4. Right-click and "View Page Source"
5. Search for "testing" and assert it is not there
6. Stop the server, go to wp-templates/page.js, uncomment the template query and save the file
7. Run the build and start the server again
8. Update the View Source page
9. Search for "testing" and assert it is there.

Additional context

Page Source screenshot:

@faustwp/core Version

2.1.2

@faustwp/cli Version

2.0.0

FaustWP Plugin Version

Using hosted example

WordPress Version

Using hosted example

Additional environment details

Using hosted example

Please confirm that you have searched existing issues in the repo.

• Yes

[rrmesquita]

To give more context, I'm not trying to create a page without remote data, as I could simply create a Next.js page for this.

Actually, I noticed this when trying to add multiple queries to a template, as described in the RFC.

[jasonbahl]

@rrmesquita thanks for reporting this!

I'd be curious to hear more about your use case for using a wp-template file if you don't require data from WordPress?

[rrmesquita]

@jasonbahl I may have expressed myself poorly. Sorry about it.

I do require data from WordPress. Actually, my use case is exactly the one described in the RFC: multiple queries, one being the page data and the other being layout/global pieces of content.

But when trying out with multiple queries and seeing that the SSR was not working, I discovered the problem described in this issue.

Let me know if I can provide more details.

[jasonbahl]

To clarify, you have Component.query or Component.queries the SSR works, but if neither are there it doesn't work and an error or some sort of debug messaging would be expected?

[rrmesquita]

Not really. The SSR only works with Component.query, but not with Component.queries. As for debug message, I couldn't see any.

[rrmesquita]

I've updated my reproduction repo to include an example of multi queries, where the SSR also doesn't work.

[jasonbahl]

Thanks! This is helpful information 🙏

[theodesp]

@rrmesquita I tried to reproduce your example but it seems that everything works as expected

Production build with no Component.query

Production build with Component.query

Production build with Component.queries

is there something we miss?

[rrmesquita]

@theodesp your screenshots show you're looking at the DOM inspection, rather than the actual page source. By the time you're looking at the DOM, the page has already been parsed, and the JavaScript has already been executed. The DOM is the result of the JavaScript execution, not the source of the page.

To view page source, right-click anywhere on the page, and click "View Page Source", right above the inspect option.

[jasonbahl]

@theodesp I was able to reproduce following @rrmesquita steps and disabling JavaScript in my browser. I only see the content if JavaScript is enabled which means this is not doing a Server Side Render but rather a client side render

[rrmesquita]

@jasonbahl @theodesp do you have any ideas on where I can take a look to help investigate this? I'm beginning a mid-size project, and getting this to work would be very useful. Also, I'd appreciate it if you could help me set up a dev environment for this repo.

[theodesp]

@rrmesquita TBH the bug is not obvious inside the getWordPressProps since we are returning data in the props as expected.
On the other hand, I would look into the FaustProvider code that updates the seedQueries
https://github.com/wpengine/faustjs/blob/canary/packages/faustwp-core/src/components/FaustProvider.tsx#L47

It could be that the use of context and useEffect would break SSR.

[rrmesquita]

Good guess, but React.useEffect is never executed in SSR.

I've run some tests, and I think the problem lies in this condition. When a query property is available, isPreview equals to false, otherwise it equals to null.

That null return on line 296 is most certainly causing this issue.

[theodesp]

cc @blakewilson

[rrmesquita]

Two other things came on mind related to this variable:

const [isPreview, setIsPreview] = useState<boolean | null>(
  templateQueryDataProp ? false : null,
);

• Why it is possible to be null, instead of true | false only?
• Shouldn't __FAUST_QUERIES__ also be considered when defining its initial value?

[rrmesquita]

Any updates on this? It seems pretty severe as it deals with SEO – also, half the fix is already pointed out here. Thanks!

@blakewilson

[blakewilson]

Hi @rrmesquita,

I'm no longer working on the Faust.js project. @theodesp or @ChrisWiegman should be able to provide you with some information on the status of this issue though.