can you please create a new GitHub issue including a minimal example?
#head fn not being called on SSR when notFound route is thrown
mossy spruce
sharp stream
Not sure I can create an example using SSR tbh. Is there a default stackblitz example I can clone?
mossy spruce
just a git repo
stackblitz does not work well with start
code sandbox works
but a git repo is enough
sharp stream
We are not using start đ
sharp stream
it goes through the same process though so I am sure I can recreate with start... so is there an example I can clone to create a repro?
I mentioned this previously but the fact we are tying router/ssr to start seems like a bit of a crazy direction. I can understand you want to push people to continue to use your tooling and frameworks BUT this feels very limiting for user that are not in the position to migrate to start. @normal cove
mossy spruce
our focus on router with SSR at the moment is start. we will be able to shift more attention to SSR in "plain" router once we hit stable in start
we don't want to push anyone to use anything
sharp stream
Cool, understood - it feels the opposite direction as it stands but that is good to know.
Can you provide me with an example for start to save me having to bootstrap a new app? or send me in a direction I can find?
For context, we do plan to migrate to start at some point but there are many factors as to why we cannot perform this migration right now.
mossy spruce
resources need to be prioritized. If you want more attention on non-start router right now you have to either contribute time or funds ...
sharp stream
Thanks, will create a repro now.
ok, I have reprod the issue using the start example. Do you want me to actually open a repo? Its literally a few lines changed
sharp stream
normal cove
To be very clear, weâre are focusing on Start as a way to achieve flexible SSR with Router. Start is on the furthest end of the difficulty scale for SSR, which makes it a testing bed for any subclass implementation.
This is why you see much of the Router api designed the way it is, so that we can support multiple implementations, frameworks, environments.
We will not be focusing on Router SSR outside of start until start is done. And also, if I can be more blunt, why would we do that first? Offering a first class solution to Router SSR that doesnât sacrifice on any features should be our first priority as opposed to spreading effort thin to support some features for many different approaches.
Similar in spirit: we chose to focus on React only at first, knowing that we would later expand to other frameworks.
I also donât like this âactively limitingâ phrasing, which feels like a needlessly negative way to spin âwe have a roadmap and priorities that require high focus on specifics goalsâ.
This is the kind of chatter that commonly surrounds Next and the idea that it only works on Vercel.
We have zero incentive to limit how people use our tools, and on the flip side, we have every incentive to prioritize features that we know will apply to the majority of users
sharp stream
I apologise for the wording, its more an observation not intended to offend. I appreciate and completely understand the reasoning though for sure. I have not seen or found a roadmap for what its worth so everything I say has to be an assumption!! We heavily rely on router and appreciate the support and have tried to feedback with valid requests and pulls where possible. I am definitely not knocking the tooling!
To note, this is an issue that is observable in Start, and I have given a base diagnosis.
Had we been building a ground up application we would have for sure used Start from the get go as the work in that area is looking great. Unfortunately we are not in that position and that migration is not easily achievable, not knocking the tooling at all.
Again, its not a personal attack on the framework/tooling you are building out more so an observation and I apologise if that came across as an attack, that was not the intention but is a growing concern that we could end up trapped on legacy versions losing support. Just to note we have been using router since prior to start and that happened to be a migration from another routing system.
Anyway, my apologies, but based on the responses I received it seemed as if it is becoming limiting
We are not using start đ
Manuel Schiller â Today at 16:04
ah
that might explain a lot```you seem to be seeing things that are not there
or read too much between the lines
what I meant is that since you are not using start, handling of notFound etc could be different than what we have implemented with start. turns out, you reproduced it in start which is good
sharp stream
I think there have been misunderstandings on both sides tbh, I do not wish to break relationships here rather build them so again my apologies if there have been misunderstandings.
mossy spruce
just dont assume we do anything in bad faith and we're good đ