`useQueryParams` Adds New History Entries When Updating Search Parameters

[rithviknishad]

Description:
When using useQueryParams hook to update search parameters, each update results in the addition of a new entry to the browser’s history.

Expected Behavior:
Ideally, updating search parameters should modify the current URL without creating a new history entry. This can be achieved by utilizing the window.history.replaceState() method.

Example:

const [query, setQuery] = useQueryParams();
setQuery({ page: 2 }); // Updates the URL's search and also adds a new history

[kyeotic]

Hi @rithviknishad, thanks for the detailed report. I understand why you might want this, but I disagree that this should be the expected behavior. Updating the url in any way should always produce a new history entry, by default.

useNavigate has a replace parameter that you can use to update the URL without creating a new entry. If thats the behavior you need, that's the method you will have to use.

I would be open to a feature PR that added a replace parameter to the useQueryParams hook, if you want to make one.

[rithviknishad]

Thanks for the guidance @kyeotic

The setQueryString callback returned from useQueryParams already has an option named replace (which replaces existing search params) and hence the naming would be conflicting.

What are your thoughts on naming it replaceNavigation instead?

raviger/src/querystring.ts

Lines 21 to 31 in 7ab724d

	const setQueryParams = useCallback(
	(params, { replace = true } = {}) => {
	let path = getCurrentPath()
	params = replace ? params : { ...parseFn(querystring), ...params }
	const serialized = serializeFn(params).toString()
	if (serialized) path += '?' + serialized
	if (!replace) path += getCurrentHash()
	navigate(path)
	},

[kyeotic]

I can see how that name is confusing, since the same name is used on useNavigate and it does something else entirely. However, the purpose of the replace parameter on setQueryString is to replace the entire querystring, rather than update only the values passed in.

Changing the name would be a breaking change, since its the key of the options object.
I would be open to adding another parameter to the options object, e.g. historyReplace or navigationReplace.
I am not open to introducing any breaking changes at this time, but I would be happy to add this to the list of things to break for vNext.

To be clear, my original suggestion was to add the parameter to useQueryParams, not setQueryString. I am still open to that, but I like adding it to the setQueryParams function more.

[rithviknishad]

Thanks for the suggestion for the names for the parameter in the options object!

We could add it to both useQueryParams and setQueryString. setQueryString could fallback to the one provided in useQueryParams's options if none provided for setQueryString.

But to maintain consistency in design, if we decide to do that, should we also consider adding that fallback for replace (replacing entire querystring option) as well to options of useQueryParams?

(Or we could just keep things simple and have it only in setQueryString)

What are your thoughts?

[kyeotic]

I think adding it just to setQueryString makes the most sense.

[rithviknishad]

@kyeotic Thanks for the guidance! I've raised a PR for the same (#135). Review would be appreciated!

Also I had noticed that the return type signature in the useQueryParams docs was having replace as an argument instead of being inside an options object. I've corrected the docs as well.

raviger/docs/api/useQueryParams.md

Lines 15 to 18 in 7ab724d

	export function useQueryParams(
	parseFn?: (query: string) => QueryParam,
	serializeFn?: (query: QueryParam) => string
	): [QueryParam, (query: QueryParam, replace?: boolean) => void]

[kyeotic]

This has been published under 4.2.0