fix: Add is404 flag for 404ed routes

[Swanand01]

What

This PR adds the is404 flag for 404ed routes

Why

Currently, when templateByUri{} resolves to a non-existent WordPress route, the 404 template gets returned, but since theres a template to return, the status code presents as a Success, instead of properly indicating (to SEO, crawlers, userland handlers) that there is no WP-route at that page.

Related Issue(s):

• https://github.com/rtCamp/headless/issues/451
• Ensure 404-ed routes return the correct HTTP Status codes #145

How

parseQueryResult in packages/query/src/utils/parse-template.ts is refactored to also parse out the flag is404.

Testing Instructions

Screenshots

Additional Info

Checklist

• I have read the Contribution Guidelines.
• My code is tested to the best of my abilities.
• My code passes all lints (ESLint, tsc, prettier etc.).
• My code has detailed inline documentation.
• I have added unit tests to verify the code works as intended.
• I have updated the project documentation as needed.
• I have added a changeset for this PR using npm run changeset.

[changeset-bot]

🦋 Changeset detected

Latest commit: c97d860

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@snapwp/query	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Swanand01]

@justlevine This here is a quick fix as recommended by @ayushnirwal:
#145 (comment)

[coveralls]

Pull Request Test Coverage Report for Build 14524438168

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 53.748%

---

Totals
Change from base Build 14477364702:	0.1%
Covered Lines:	400
Relevant Lines:	661

---

💛 - Coveralls

[justlevine]

LGTM with some small notes below.

That said, since this PR doesn't seem to actually do anything with / allow usage of is404 and since connectedNode is an unnecessary perf hit. I'm going to put this on hold.

If exposing template date or fixing the error codes gets unblocked before snapwp-helper can expose a templateByUri.is404, then we'll merge this as a temporary fix. Otherwise, we'll update this to use that eventual field.

[Swanand01]

@ayushnirwal This PR for now just returns the is404 property from the parseQueryResult. However, it is still not accessible in the user land. Any ideas on how that can be achieved?

[Swanand01]

In TemplateRenderer:

const { editorBlocks, bodyClasses, stylesheets, scripts, scriptModules, is404 } =
		await getTemplateData( pathname || '/' );
<main>
    <div className="wp-site-blocks">
        { children( { editorBlocks, is404 } ) }
    </div>
</main>

export default function Page() {
	return (
		<TemplateRenderer>
			{ ( { editorBlocks, is404 } ) => {
				return <EditorBlocksRenderer editorBlocks={ editorBlocks } />;
			} }
		</TemplateRenderer>
	);
}

We can expose the is404 to user land this way.

[ayushnirwal]

We can redirect to next's 404 page if is404 is true. If next provides ways to attach status code we can do that.

[justlevine]

We can redirect to next's 404 page if is404 is true. If next provides ways to attach status code we can do that.

The acceptance criteria for https://github.com/rtCamp/headless/issues/451 is to use WordPress as the source of truth for the 404 template while providing user control of status codes based on WPGraphQL-exposed data. I don't think a component-level redirect is an "ideal" DX solve for this, but we can refine it in a follow-up PR.

[Copilot]

Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.

Files not reviewed (1)

• packages/query/src/queries/get-current-template.graphql: Language not supported

Comments suppressed due to low confidence (1)

packages/query/src/utils/tests/parse-template.test.ts:90

• There is no test case for when 'templateByUri' is undefined; consider adding one to ensure the 'is404' flag defaults to false in that scenario.

});

[ayushnirwal]

@Swanand01 I don't know how you arrived at the middleware solution.

Try using the notFound function along with not-found.js file.

1. Create a not-found file that fetches template data for WP 404 page. Since this fetch does not rely on any dynamic parameters, it will be statically built.

2. In Template Renderer, call the function notFound.

@justlevine Is there a reliable URI to get the 404 template in (1) through templateByURI? or any other way?

If no, we can use a garbage URI to fetch 404 template data for now and later update the backend to remove the hack.

[Swanand01]

@SH4LIN I don't know how you arrived at the middleware solution.

Try using the notFound function along with not-found.js file.

1. Create a not-found file that fetches template data for WP 404 page. Since this fetch does not rely on any dynamic parameters, it will be statically built.
2. In Template Renderer, call the function notFound.

@justlevine Is there a reliable URI to get the 404 template in (1) through templateByURI? or any other way?

If no, we can use a garbage URI to fetch 404 template data for now and later update the backend to remove the hack.

What if we use TemplateRenderer in not-found.tsx?

export default function NotFound() {
	return (
		<TemplateRenderer>
			{ ( { editorBlocks } ) => {
				return <EditorBlocksRenderer editorBlocks={ editorBlocks } />;
			} }
		</TemplateRenderer>
	);
}

[ayushnirwal]

What if we use TemplateRenderer in not-found.tsx?

Yes...

[justlevine]

Is there a reliable URI to get the 404 template in (1) through templateByURI? or any other way?

There's currently no way to fetch just a template and not a "resolved" URI. Ideally it would be the same results of the previous query - either via the app or because we have server-side caching. I know most things are locked down, but even just requerying the same URI will give us what we need.

If no, we can use a garbage URI to fetch 404 template data for now and later update the backend to remove the hack.

I'm not opposed to this as a temporary workaround.

[justlevine]

Remaining open comments + docs, and this should be good to merge.

(If we cant import getTemplateData() to userland until #144 , then we can doc the ideal dx and then put this on hold until that's possible. )