hide `/__data.json` from the `url` object inside `handle`

Describe the problem

I find it weird that the url object inside handle in hooks.server.ts differs from the url object passed to the route files.

In the end, the /__data.json information from the route is just for the resolve function to distinguish what it should return.

Use-cases I see problematic with the current approach:

• redirecting in case of an unauthenticated request and saving the current information as a “redirectTo” parameter This works fine as long as you directly access /dashboard/project1 in the browser, but if you would get redirected via a client-side navigation, the “redirectTo” parameter will be /dashboard/project1/__data.json
• logging: when I want to track how many requests were made to /dashboard/project1 I would also need to look for /dashboard/project1/__data.json entries (assuming I log all accesses with its url from within hooks.server.ts)

It is easy to make a workaround for those usecases and manually remove the /data.json at the end of the url, but you first have to discover that this “issue” exists. I see this as a hurdle for new or inexperienced users.

And I also see it problematic if e.g. for some reasons __data.json gets renamed to __data.json5 or __data.xml in the future to support other content formats. Then the workarounds will no longer work.

Here is a small project demonstrating a problematic logging issue: https://stackblitz.com/edit/sveltejs-kit-template-default-sllc4q?file=src/hooks.server.ts

1. Click on the “page 1” link
2. Reload the page
3. See that both requests resulted in different log outputs

Describe the proposed solution

Use the same url object within hooks.server.ts (without /data.json at the end) and add a new attribute to the event object to distinguish between regular requests and data requests.

This would mean a breaking change, but the migration process should be fairly simple.

Alternatives considered

Leave it as it is

Importance

would make my life easier

Additional Information

No response

[Rich-Harris]

No, I mean that an older version of SvelteKit did exactly what patchHandle does (minus the isLoadRequest property, plus trailingSlash handling). I suspect part of the problem was that it made it impossible to know if you were serving an HTML or data request, which isLoadRequest solves.

Marking as a 1.0 milestone issue since if we change this it needs to happen before then.

[dummdidumm]

Aaaah thank you, that’s exactly the comment I remembered. Glad to hear the boolean would solve that for you!