Route head function not called if rendering notFoundComponent

[GregoryCollett]

Which project does this relate to?

Router

Describe the bug

Note:
we are attempting to bump from 1.86.1 to 1.112.11

Context:
We are running our own SSR server and have not yet migrated to start BUT the repro provided is using start.

The issue only occurs on SSR (test case is simulating google bot/crawlers without JS)

I have a case where we have a head fn on a route that can provide meta data for both matched or notFound depending on the data return from loaderData. The notFound is thrown from a child route and bubbles up as I would expect it to BUT the head fn on the route is no longer called as I would expect. This is only an issue when we are rendering the notFoundComponent, the standard use case still works as expected.

This had been working previously without issues. Any advice?

Your Example Website or App

https://github.com/GregoryCollett/tanstack-ssr-head-bug

Steps to Reproduce the Bug or Issue

• Run app
• Set network conditions to simulate google bot
• Disable Javascript
• Go to posts
• Navigate through posts and see the title is changing as expected
• Navigate through to non-existing-post and see the meta data is not updated as expected and the head function is not called.

Expected behavior

As a developer, I expect the head function to be called so that I can render relevant meta data but I am seeing that the head function is not called at all meaning I cannot output relevant meta data e.g. Post not found

Screenshots or Videos

No response

Platform

• OS: ALL
• Browser: ALL
• Version: N/A

Additional context

No response

[GregoryCollett]

Have been doing a little digging and please bear in mind this is all "theory" based on reviewing code. I have not actually tested this yet (I will create a branch on my repro repo based on an earlier commit if I find the time) but the change linked is where I believe this became an issue.

8dbbe93#diff-2ac234f610fa0e0c2146252c10a5266af9c5b6d0b63659a0fa4c9f2c4472596aL1383-L1392

This is fully assuming that match.status does not get set to success in the case of notFound (I am not sure if it does or not, have not yet debugged this).

As I say, I will double check this theory if I find the time.

[schiller-manuel]

This is fully assuming that match.status does not get set to success in the case of notFound

this is not a problem per-se as the head fn is called after loader finished.
but when the loader throws a notFound (or really anything), head won't be executed.
this begs the question: should we call head without loaderData?

[GregoryCollett]

Thanks for your response.

Yeah, I also spotted this in code review. This is a change in behaviour from previous versions. Is there a reason to enforce loader success if we still end up in the same route albeit rendering a different component?

I feel head should be called regardless of loader success or failure - potentially with additional context e.g. the error caught, I am sure there are a number of cases where developers would want to change meta data based on these scenarios e.g. to render different title meta data or to update other bits like robots no-index as not all bots/crawlers abide by the 404 status code (although google does). The same would also apply to OG/twitter card tags etc whereby you may want to show specific meta in a user facing context for the not found case.

Would be keen to discuss and understand this more.

Cheers!

[schiller-manuel]

the primary reason was to simplify types as the current approach allowed to make loaderData non-nullable.

head should probably be called in your scenario, and types should reflect that.
if an error/notFound happened, loaderData would be never

we need to think about this more and take into account all possible scenarios, e.g.

• when a notFound is thrown
• when any error is thrown
  what if the error bubbles up? do we still render the route and it's head/meta?

[GregoryCollett]

That makes sense as we have definitely had to code protectively to account for potential null loaderData in our current instance.

Yeah that makes complete sense, I am honestly unsure of all the scenarios it can end up in but will do a little more digging and note any additional scenarios I find.

Thanks!

[GregoryCollett]

Please excuse my naivety when it comes to the code, I now see what you mean r.e. the handling of not found or redirect cases.

The question around bubbling, Is there an expectation that if there is no notFoundComponent that it raises to the next and so on? Sorry just trying to get an understanding of the current lay of the land. I haven't had a chance to look any further unfortunately BUT would be interested in gaining a better understanding of how these bits tie together.