feat(gatsby): handle search params in resource loader

[pieh]

Description

SSR allows making use of query params but our runtime is right now adjusted to make it work well:

• initial page load will have html that make use of serverData produced with proper query params, but later we fetch page-data without those params and there is potential flicker ( fix(gatsby): fix hydration flicker on initial render of ssr page #33134 doesn't work with it without doing more changes)
• client side navigation (with gatsby-link) just strips query params and make use of pathname

[ch38142]

[pieh]

This was causing some race condition where runtime behaviour is not deterministic. Specifically

gatsby/packages/gatsby/cache-dir/production-app.js

Line 166 in 17a3f9f

window.___webpackCompilationHash = page.page.webpackCompilationHash

might not be executed before this check

gatsby/packages/gatsby/cache-dir/navigation.js

Lines 105 to 112 in 17a3f9f

	// window.___webpackCompilationHash gets set in production-app.js after navigationInit() is called
	// So on a direct visit of a page with a browser redirect this check is truthy and thus the codepath is hit
	// While the resource actually exists, but only too late
	// TODO: This should probably be fixed by setting ___webpackCompilationHash before navigationInit() is called
	if (
	pageResources.page.webpackCompilationHash !==
	window.___webpackCompilationHash
	) {

[pieh]

Result of https://github.com/gatsbyjs/gatsby/pull/33209/files#r717559851

Please note that with this change it is actually same as we check client navigation in

gatsby/e2e-tests/production-runtime/cypress/integration/redirects.js

Lines 62 to 71 in 17a3f9f

	it(`should support hash parameter with Link component`, () => {
	cy.visit(`/`, {
	failOnStatusCode: false,
	}).waitForRouteChange()
	cy.getTestElement(`redirect-two-anchor`).click().waitForRouteChange()
	cy.location(`pathname`).should(`equal`, `/redirect-search-hash`)
	cy.location(`hash`).should(`equal`, `#anchor`)
	cy.location(`search`).should(`equal`, ``)
	})

And same for 2 following changes

[pieh]

This was breaking some code paths in e2e/prod-runtime tests that were previously not exposed because engines were not generated (this PR adds first SSR pages, so this code path was finally hit in those tests).

Later we have request handler for matchPaths (SSG matchpaths, not handled by engine) and sending 404 was just blocking it. We still have final fallback 404 later in final request handler.

[wardpeet]

I think you can rewrite this into this:

Suggested change

	const maybeQueryString = Object.entries(req.query)
	.map(([k, v]) => `${k}=${v}`)
	.join(`&`)
	if (maybeQueryString) {
	searchString = `?${maybeQueryString}`
	}
	searchString = new URL('http://localhost:8000/test?q=234').search

[wardpeet]

The test seems to catch what we want to catch and code looks fine so 👍