Handle page not found status code
Kingdutch opened this issue · 3 comments
It's easy to create a fallback page for when a page is not found. However, the result of this is that when this catch-all route is matched the status code is still 200 rather than 404. Especially when a browser tries to load some kind of asset this may be problematic.
I wonder what the most ergonomic way to handle this would be. I wouldn't want to introduce actual variants here, because it'd be... painful. One could maybe consider (ab)using exceptions here?
As for the status code, it's... hard with streaming. But essentially, we could probably quite easily build something that'll allow you to just match the route you're asking for, so you can call into that before even kicking off rendering. Let's let this marinate a bit...
I think in my mind the answer here would be to do this in prepare? Which would know all this before we get to the UI. Allowing prepare to interject in the status code, rather than simply return data could also solve #24 in the same way by allowing prepare to do the redirect in case authentication is required.
I realize I bring up Remix a lot, but they solved this in a similar manner by giving loader the power to return an HTTP response rather than data that's passed to the page. I think it's a sensible solution.
What issues would it cause if prepare was given this same power?
We need to be very careful here so we don't mix up concepts. prepare is strictly to prepare the next route - the whole point is that it shouldn't be blocking, or even evaluate what it is it's getting back. Is should simply, as fast as possible, initiate whatever fetching is needed, but nothing more.
So the Remix comparison isn't apples to apples. Remix also works very differently, and does not have the concept of preparing a route, only of actually blocking rendering until data is fetched. They'll have the same problems as they introduce more granular streaming/defer parts of the response.
I think a function via context that calls into the server directly is a potential approach here, as described in a related issue.