New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for search #58
Comments
I think it is better to return a complex location object, as in RR
|
@worudso @dpr-dev Hey guys, thanks for the issue. // useLocation hook may return a third argument, which is basically a hash
// of query params used; this is completely optional and apps that use
// the hook already won't break
const [location, setLocation, queryParams] = useLocation();
// the signature of the useRoute hook stays the same, however it may return query params
// in the params hash along with dynamic segments
const [match, params] = useRoute("/app/users/:id");
// example: /app/users/alex?tab=settings
// -> { id: "alex", tag: "settings" } In my opinion this can be one of the optimal solutions because:
Anyway, let me know what you think about this design? |
This is my fork I'm not saying we'd better go The current version of my But there's a problem that there can be more than two params with the same name at once(This kind of usage actually exists in my project). And I think we'd hetter leave this problem(manipulating search params in an elegant way) to another utility library(lodash, immer, etc) and a programmer himself, and focus on conservative representation of And there's another problem that with
So I 100% agree with new |
@worudso Not sure if I understand what you mean by:
You mean the search query might contain things like |
@molefrog yes, that's the case. Whether it's recommended or not, it's already supported by native |
@molefrog, very nice implementation |
@molefrog's implementation looks like what we need now. Looking for a "hash" property also https://www.w3schools.com/jsref/prop_loc_hash.asp |
Has this landed? |
I think separating For now, to track I like the separation in react-use between:
I believe this library should do the same due to performance reasons and ability for a project to import only what's needed for their specific needs. |
Any news about this? It would be great to have access to the search map! |
I tried to use the const getValue = (param) => new URLSearchParams(window.location.search).get(param)
function useSearchParam(param) {
const [value, setValue] = useState(() => getValue(param))
useEffect(() => {
const onChange = () => setValue(getValue(param))
window.addEventListener('popstate', onChange)
window.addEventListener('pushstate', onChange)
window.addEventListener('replacestate', onChange)
return () => {
window.removeEventListener('popstate', onChange)
window.removeEventListener('pushstate', onChange)
window.removeEventListener('replacestate', onChange)
}
}, [param])
return value
} This is because the events they are listening to are I'm leaving this here in case someone else also runs into this problem when using react-use with wouter. |
Correct me if I'm wrong but it looks like an update in regards to joaopaulobdac's issue above means a component will rerender if the query params change. So I believe you can just use import { useLocation as useWouterLocation, useRoute as useWouterRoute } from "wouter";
export const useLocation = () => {
const [location, setLocation] = useWouterLocation();
return [location, setLocation, window.location.search];
};
// const [location, setLocation, search] = useLocation();
export const useRoute = (pattern) => {
let [match, params] = useWouterRoute(pattern);
if (match) {
const urlSearchParams = new URLSearchParams(window.location.search);
const queryParams = Object.fromEntries(urlSearchParams.entries());
// params and queryParams can have the same name
// this preferences params in that scenario
params = {
...queryParams,
...params,
};
}
return [match, params];
}
// const [match, params] = useMatch(pattern); |
is it possible to add search dynamically? https://codesandbox.io/s/wouter-demo-nested-routes-forked-qmg6q?file=/src/index.js when pressed add query it will add query but remove previous params. how to test: |
Copying and pasting my response from #177: The correct way to do this would be something like the example shown here: #232 const events = ["popstate", "pushState", "replaceState", "hashchange"];
function subscribe(callback: () => void) {
for (const event of events) {
window.addEventListener(event, callback);
}
return () => {
for (const event of events) {
window.removeEventListener(event, callback);
}
}
}
function getCurrentValueOfMyParam() {
return someFunctionOf(window.location);
} And now we can simply do... const myParam = React.useSyncExternalStore(subscribe, getCurrentValueOfMyParam); No re-rendering if (Notice: no mucking with |
Any solution ? |
It works for me. import React from "react";
import ReactDOM from "react-dom/client";
import { Router } from "wouter";
import useBrowserLocation from "wouter/use-location";
import App from "./App";
ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
<React.StrictMode>
<Router
+ hook={(options) => {
+ const { pathname, search } = new URL(location.href);
+
+ const [_, nav] = useBrowserLocation(options);
+
+ return [pathname + search, nav];
+ }}
>
<App />
</Router>
</React.StrictMode>
); |
In the latest version of wouter, when the location is
somewebsite.com/users?name=john
location
only retrieves/users
emitting?name=john
. And even though I push new query params with other methods, re-rendering is not triggered. But sometimes a view needs to depend on search params.I think we have two options in a broad sense
add
useSearch
thingor we can let wouter give
searchParams
as aURLSearchParams
object, the parsed one.or how about
useURL
which gives current location as URL object?let
location
belocation.pathname + location.search
.In this case, we got a new problem to redefine routing rules. Should
useRoute
provide matching for search parameters? I don't think so. Routing rules can go the same just ignoring search.And the parsing for
location.pathname + location.search
is annoying. AFAIK, there is no builtin function to parse it. And even if there is, the code to parse would be repeated in many components.The text was updated successfully, but these errors were encountered: