After playing around and some debugging, I notice that when I do

packages/wouter/src/use-browser-location.js

export const useSearch = ({ ssrSearch = "" } = {}) => {
  return useLocationProperty(
    () => location.search,
    () => ssrSearch
  );
};

Instead of

const currentSearch = () => location.search;

export const useSearch = ({ ssrSearch = "" } = {}) =>
  useLocationProperty(currentSearch, () => ssrSearch);

The issue seems to be fixed. Could this be a potential bug with how the library uses useSyncExternalStore?

If this is really the cause of the bug, does that mean that usePathname and useHistoryState could potentially having the same exact issue as well?

export const useSearch = ({ ssrSearch = "" } = {}) =>
  useLocationProperty(
    () => location.search,
    () => ssrSearch
  );

// ...

export const usePathname = ({ ssrPath } = {}) =>
  useLocationProperty(
    () => location.pathname,
    ssrPath ? () => ssrPath : location.pathname
  );

// ...

export const useHistoryState = () =>
  useLocationProperty(
    () => history.state,
    () => null
  );

I am guessing, when we define

const currentSearch = () => location.search;

The value of currentSearch got "memorised" during initialisation, which causes this issue...

Any thoughts / comments are welcomed!

@junwen-k Hi! My guess it that useSearchParams from RR isn't compatible with wouter and it requires a separate implementation which is wouter-specific. I have an idea, as an experiment, use this dummy hook instead:

const useSearchParams = () => {
  const [,navigate] = useLocation()
  const search = useSearch()
  const params = new URLSearchParams(window.location.search)

  const setSearchParams = (obj) => {
    navigate(`?tab=${obj.tab}`)
  } 

  return [params, setSearchParams]
}

Also, take a look at #391

@junwen-k Hi! My guess it that useSearchParams from RR isn't compatible with wouter and it requires a separate implementation which is wouter-specific. I have an idea, as an experiment, use this dummy hook instead:

const useSearchParams = () => {
  const [,navigate] = useLocation()
  const search = useSearch()
  const params = new URLSearchParams(window.location.search)

  const setSearchParams = (obj) => {
    navigate(`?tab=${obj.tab}`)
  } 

  return [params, setSearchParams]
}

Hi, thank you for replying. I've tested with the above snippet and the issue seems to persist. 👀
The behaviour is very buggy as you can see that sometimes it "works".

useSearchParams.ts

import { useLocation, useSearch } from "wouter";

export const useSearchParams = () => {
  const [, navigate] = useLocation();
  const search = useSearch();
  const params = new URLSearchParams(window.location.search);

  const setSearchParams = (obj) => {
    navigate(`?tab=${obj.tab}`);
  };

  return [params, setSearchParams];
};

You can see that for a split second, Tab 3 works for a while, then it won't work again 🤷🏻‍♂️

(0:20: Refresh with ?tab=3 as default)
(0:22, 0:24: Tab 3 is selected and worked as expected?)

Right, I was able to reproduce it locally. What bothers me is that React Router also doesn't re-render when the query string changes from the outside. Try running: history.pushState(null, "", "/?tab=3") and you will see that the tab isn't updated.

I notice that when I do

const subscribeToLocationUpdates = (callback) => {
  for (const event of events) {
    addEventListener(event, (...props) => {
      console.log("event", event, ...props);
      callback(props);
    });
  }
  return () => {
    for (const event of events) {
      removeEventListener(event, callback);
    }
  };
};

Console actually output:

event pushState Event {isTrusted: false, arguments: Arguments(3), type: 'pushState', target: Window, currentTarget: Window, …}

Which means pushState event is working. When I inline the arrow callback and it works as expected.

export const useSearch = ({ ssrSearch = "" } = {}) =>
  useLocationProperty(
    () => location.search, // Inlined
    () => ssrSearch
  );

May I know if this is not the right approach? I have the impression that somehow the value of location.search gets memorised or something.

I've also noticed that react-router discourage users to manipulate URLs using the history object directly.

⚠️ IMPORTANT
For illustration only, don't use window.history.pushState directly in React Router

Not sure if running history.pushState(null, "", "/?tab=3") not working for react-router was due to that.

Not sure if running history.pushState(null, "", "/?tab=3") not working for react-router was due to that.

I did some digging: React Router uses its own format of state object to perform navigation. It is not designed to be compatible with external routers, and that is completely okay as it means that wouter doesn't break it. So I narrowed down the example to only include wouter and did two experiments:

1. Instead of using useSearchParams I use useLocation (as well as useHashLocation) to extract the current tab number from the URL, e.g. /1
2. Replaced that hook with a simple useState

Interestingly, 2) works well, while 1) is still broken. It proves that the issue is indeed in wouter, but it also tells us that it's not just the search string hook.

I'll keep looking

Hey @junwen-k any update on this? I'm curious if you found out the issue.

Hey @junwen-k any update on this? I'm curious if you found out the issue.

Hi, thank you for following up. As mentioned earlier, I've actually found out a solution that worked on my end.

The changes that fixes the issue was:

- const currentSearch = () => location.search;
- 
export const useSearch = ({ ssrSearch = "" } = {}) =>
- useLocationProperty(currentSearch, () => ssrSearch);
+  useLocationProperty(
+    () => location.search,
+    () => ssrSearch
+  );

I am also wondering if we should change history as well:

- const currentHistoryState = () => history.state;
-
export const useHistoryState = () =>
-  useLocationProperty(currentHistoryState, () => null);
+  useLocationProperty(
+    () => history.state,
+    () => null
+  );

However as mentioned earlier, I am not sure if this is the right approach to the issue.

I have the impression that somehow the value of location.search gets memorised or something.

Currently as a workaround, I am using my upstream branch which you can take a look here. Note that this is tightly related to #391 as the useSearchParams hook won't really work without this fix.

Suffering from the same bug. Would appreciate if the connected PR was merged soon.