data-sveltekit-replacestate does not work for #hash links

[edde746]

Describe the bug

When clicking on a hash link that has the data-sveltekit-replacestate attribute, the expected behavior is to update the URL without pushing a new history entry. However, the bug causes the history object to be pushed even when the data-sveltekit-replacestate attribute is used, resulting in unexpected navigation history behavior.

Reproduction

https://stackblitz.com/edit/sveltejs-kit-template-default-jsaxq9

Steps to reproduce the behavior:

1. Create a new SvelteKit project or open an existing one
2. Add a hash link with the data-sveltekit-replacestate attribute, like the following: <a data-sveltekit-replacestate href="#c">c</a>
3. Start the development server and navigate to the page containing the hash link
4. Click on the link with the attribute
5. Observe the URL change and the browser's navigation history

Logs

No response

System Info

Not applicable

Severity

annoyance

Additional Information

No response

[vicentematus]

I think i know why this is happening:

We have the following options element which contains:

kit/packages/kit/src/runtime/client/client.js

Line 1530 in 5191e16

const options = get_router_options(a);

It returns an object which contains replace_state, which is a boolean. It activates whenever we click on a div which contains data-sveltekit-replacestate. It will return options.replace_state as true This is working as expected.

But we have a problem, because whever we click, the logic of only updating the hash will update.That will trigger the pushHistory Which is the following

kit/packages/kit/src/runtime/client/client.js

Lines 1564 to 1592 in 5191e16

	const [nonhash, hash] = url.href.split('#');
	if (hash !== undefined && nonhash === location.href.split('#')[0]) {
	// set this flag to distinguish between navigations triggered by
	// clicking a hash link and those triggered by popstate
	// TODO why not update history here directly?
	hash_navigating = true;
	update_scroll_positions(current_history_index);
	current.url = url;
	stores.page.set({ ...page, url });
	stores.page.notify();
	return;
	}
	navigate({
	url,
	scroll: options.noscroll ? scroll_state() : null,
	keepfocus: options.keep_focus ?? false,
	redirect_chain: [],
	details: {
	state: {},
	replaceState: options.replace_state ?? url.href === location.href
	},
	accepted: () => event.preventDefault(),
	blocked: () => event.preventDefault(),
	type: 'link'
	});

Even if options.replace_state is true, it will always enter this if condition and push the store because of the stores.page.set. It will never reach the expected navigate function which has the logic of triggering the replaceHistory.

This is the function that is expected to replace the state with replaceState

kit/packages/kit/src/runtime/client/client.js

Lines 1580 to 1593 in 5191e16

	navigate({
	url,
	scroll: options.noscroll ? scroll_state() : null,
	keepfocus: options.keep_focus ?? false,
	redirect_chain: [],
	details: {
	state: {},
	replaceState: options.replace_state ?? url.href === location.href
	},
	accepted: () => event.preventDefault(),
	blocked: () => event.preventDefault(),
	type: 'link'
	});
	});

One way of dealing with this is to check in the if condition the options.replace_state:

if (
      hash !== undefined &&
      nonhash === location.href.split('#')[0] &&
      !options.replace_state
    ) 

In that way we can assure that if we trigger the data-sveltekit-replacestate the store will never push. It will reach the navigate function which is in charge of the logic of replacing the state.

[nosovsh]

@vicentematus thanks for the explanation. Are you planning to release this?

[vicentematus]

@vicentematus thanks for the explanation. Are you planning to release this?

No sir, im not currently working on it. Its free to work on it if you want (or anyone else reading this) 🤖

[sweetamino]

+1 I ran into this too. Would be nice to have a fix. What I did was just use the format href="/myPage?showModal" rather than href="#showModal" with data-sveltekit-replacestate which works as expected.

[teemingc]

Sorry this flew under the radar. I managed to see it thanks to a GitHub browser extension I just installed that sorts issues by comment date.