New approach to handle search parameters with useLocation hook (Ignore)

[ghost]

Hi, everyone Ned here ✌

I've been wondering about the search parameters and had an idea about the re-render on change problem (Just brainstorming about it).

Current approach

As of now, any change to the routes can trigger a re-render when using useSearchParams().
However, I'm most curious about if it's actually necessary to trigger those changes for everything or even the functionality of useSearchParams() 🤔
I know it can be necessary in some use cases, but still, should we? in this way?

The idea

Update on pathname changes and expose an new API to use inside useEffect() with methods to set, replace, and get search parameters wouldn't be a better approach?

Thinking about re-rendering whenever a search parameter changes just doesn't feel right.

The current way goes against some pretty useful functionalities, like controlling scope based on the parameters.

For example, the sign-in process could be controlled together with an /signin/identify?flow=email&service=SignIn in the URL where the flow can change from email to password when click an button, but there's no need to re-render everything because of it. (If you think this is not used, this pattern is used by multiple giant tech companies like Google)

Is this possible?

Look at this example:

// Inside an React.FC
const { pathname, route } = useLocation()

useEffect(() => {
    route.get({ query: 'all' }) // '?flow=email&service=SignIn' or just return an ES6 Map or Object
    route.add({ query: { flow: 'password' }}) // update route search parameters to '?flow=password&service=SignIn'
},[])

And hash could be handled like this:

route.get({ hash: 'all' })
route.add({ hash: '#react-router' })

This way we could handle the search parameters in a much more efficient way, while giving room for the user to do what they want with the API; like add the get() result to an memoized variable or state to then consume it.

The add() could just assign the query to the URL (it's pretty easy to do this if we can use URLSearchParams internally).

Usage

1. The changes would be controlled by the user with the useState() hook, context API, or state management library;
2. Which then could be reflected in the URL with route.add() or route.set();
3. The other way around would only reflect on page load when using route.get();

Route definition

and the Route definition could be like this:

<Routes>
  <Route path="/signin" element={<>Sign In</>}>
      <Route path="identify:true" element={<>Identify</>}/>
  </Route>
</Routes>

The reason why it's because we handle the more detailed part with backend services, so just making sure the route expects or not an parameter, and exposing an API to handle those parameters could solve the problem, right? or I'm kinda nuts about this?

In my view being able to define that route path expects or not an parameter could be pretty useful of a feature 🤔. Which, by now, in version 6 I have yet to see this working properly.

Anyway, be nice with me Gods of the React world, I'm kinda new about this and just trying to help 😄

[ghost]

I took a closer look at the project, and it seems that my idea can't fit here.

The purpose of this project appears to be different. Which I like, but it doesn't fit what I'm looking for.

A more powerful API to handle more particular scenarios might address the problem. However, it would also raise the bundle size and go against what this project seems to be heading to.

In the end, creating my own might be the only way.

Nevertheless, thanks, have a nice one everyone! ✌️