Redirect with hashtag from server gets stripped in InertiaJS

Versions:

• @inertiajs/inertia version: 0.9.1
• @inertiajs/inertia-vue version: 0.6.1

Describe the problem:

I have a Laravel app, where I want to redirect with a hashtag (e.g. example.com/page#hash) but the hashtag gets stripped.

It seems this is the line preventing hashtags to come along:

https://github.com/inertiajs/inertia/blob/master/packages/inertia/src/router.ts#L275 https://github.com/inertiajs/inertia/blob/211f49b98928b0f5f366387b6fbf99a65e4a07be/packages/inertia/src/url.ts#L42

Is it possible to allow hashtags? Might be cool if this would be configurable, like:

this.$inertia.post('/url', {foo: bar}, {allowFragments: true});

Steps to reproduce:

In a Laravel app, do:

return redirect()->route('my-page', '#hash');

Or:

return redirect()->route('my-page')->withFragment('hash');

And see results in InertiaJS, in default Laravel + Blade it works fine, the hashtag remains in the URL.

[claudiodekker]

Not right now, that’s what the issue is about 😉

[aidan-casey]

In a traditional Laravel + Blade app, the server returns a redirect response with a Location header. The browser then sends the request to the URL specified in the Location header (which would include the URL fragment). There’s nothing funky going on here and it is working as the browser should.

In the case of Inertia, it’s not being made aware of the Location URL (with the hash) because it is utilizing Axios under the hood which is just following the redirect without making Inertia aware of the fragment in the destination URL. Inertia is then updating the current URL and browser history with the URL in the JSON Inertia response from Laravel (which doesn’t include the fragment).

In order to get this working, Inertia technically needs to intercept the redirect response, store the hash fragment client side, make the request to the destination, and finally append the hash back onto the URL once done as it does with normal visit requests without a redirect.

Edit: @RobertBoes did some further digging on this and actually found we wouldn’t even be able to intercept the redirect client-side to read the Location header. This is according to specs for XMLHttpRequest and fetch. This essentially leaves us without much ability to solve the underlying issue.