Need a hook to get parameters - useParams

[m4n1ac47]

You need to make a custom hook useParams to get the route parameters.

import  { useParams }  from "wouter"

const Component = (props) => {
   const { id } = useParams()
  
   return (
     <div>{ id }</div>
  )
} 

Your solution that you provided in the comment is not suitable for complex cases, you have to constantly write the path. Sometimes it is complex and has a regular expression, and it is not a good idea to write it all the time.

const Component = () => {
  const [, params] = useRoute("/user/:name");
  return <div>{params.name}</hi>
};

Your example is simple, now let's see how we can get the parameters from the given route. /en/product/gamepad-sony-dualshock-4-v2-cuh-zct2e-8

const Component = () => {
  const [, { id, lang }] = useRoute('(/)*:lang([a-z]{0,2})/product/([a-z0-9-_]*[-_]*)*:id')
  return <div>{id}</hi>
};

Also, this solution is not suitable when you need to access the parameters, when the component is universal and it does not know how the routes are described in the application.

[cbbfcd]

This is a previous discussion item, I remember the point of disagreement is whether it needs to be provided by wouter or defined by the user.

[m4n1ac47]

I think this should be available in the default library because it's a much needed feature. It will be much more convenient and better if this function is made by the Wouter authors, because third-party developments cannot guarantee the same level of quality and optimization. For some it will work well, for others there will be bugs.

And it's just nicer when many good ones are available out of the box.

[cbbfcd]

maybe will be supported in wouter-next

[yairEO]

There is a native browser API for this, why do you need this library to waste a single byte of code doing what is already available out-of-the-box?

https://stackoverflow.com/a/9870540/104380

[m4n1ac47]

You are talking about query params. I'm talking about route parameters. Try to take /admin/panel/product-offer/4598/product/246 these parameters and understand what is what. It should be in the library because it's convenient.

const { offerId, productId } = useParams()

There is a native browser API for this, why do you need this library to waste a single byte of code doing what is already available out-of-the-box?

[yairEO]

what are "route params"? everything should always be in the window URL query so when the user refreshes, the state will persist

[molefrog]

what are "route params"? everything should always be in the window URL query so when the user refreshes, the state will persist

@m4n1ac47 Actually meant parameters extracted from a route e.g. "/home/:foo/:bar should give you { foo: .., bar: ...}, not query parameters.

Also, please be respectful, your tone is offensive to others.

[yairEO]

It's a cultural issue. I have no idea what might sound offensive to you since in my culture this is considered normal, everyday talk. I have zero idea what specific word triggered you or frightened you. I did not use any offensive words so your reaction saying it is offensive seems super bizarre.

I am the author of TONS of open source projects and am writing endlessly on Github and Stackoverflow and no one complains except you

[antoniobologna]

what are "route params"? everything should always be in the window URL query so when the user refreshes, the state will persist

@m4n1ac47 Actually meant parameters extracted from a route e.g. "/home/:foo/:bar should give you { foo: .., bar: ...}, not query parameters.

Also, please be respectful, your tone is offensive to others.

I'm sorry, I did not find @yairEO 's words offensive.

In any way, Wouter is phenomenal, FYI I stumbled onto this thread since I was looking for a way to extract search parameters :D

[josuevalrob]

what are "route params"? everything should always be in the window URL query so when the user refreshes, the state will persist

So, how do I get issue number from this url https://github.com/#/molefrog/wouter/issues/245

export const getParam = (position: number): string =>
    new URL(window.location.href.replace('#/', '')).pathname.split('/')[
        position + 1
    ] ?? '';

Basically this ticket is asking for the same functionality that we have in react router: useParams().

Is not that the api can or can not handle it. but for a SPA the browser api is one step far away. For example we have the # in the url and that complicate the things.

So i have to grab the url, remove the # and create a new url, and then... use the browser API.

Could be very good, if the library can handle all that instead of the one who is implementing the library for building a SPA. 😅

[yairEO]

I am against this, because I would prefer this lib to remain as slim as possible, and it is up to a developer if they want to remove a prefix such as # (which I don't understand why they use it in the first place and why should it be removed if they are using it...)

Any text manipulation should be done by the developer and not be bundled by this lib, IMHO

[josuevalrob]

I am against this, because I would prefer this lib to remain as slim as possible, and it is up to a developer if they want to remove a prefix such as # (which I don't understand why they use it in the first place and why should it be removed if they are using it...)

Any text manipulation should be done by the developer and not be bundled by this lib, IMHO

just for reference about the # https://dev.to/thedevdrawer/single-page-application-routing-using-hash-or-url-9jh

[HansBrende]

@m4n1ac47 why not just do this:

const Component = ({lang, id}) => {  
   return (
     <div>{ id }</div>
  )
}

<Route path="/:lang/product/:id">{({id, lang}) => 
   <Component id={id} lang={lang}/>
}</Route>

Regexes aren't supported anyway.

---

@josuevalrob easy:

<Route path="/molefrog/wouter/issues/:issueId">{({issueId}) =>
    <div>Issue #{issueId}</div>
}</Route>

If you are talking about hash-based routing, you'd need to write a custom location hook for your top level router to use hash-based routing instead of path-based routing.

[molefrog]

I don't think think we're going to support this anytime soon. Thank you all for the discussion.

[yairEO]

What? just like that, without a reason? Would be nice to tell your users why you're not going to support this anytime soon, and even though, why close this. What's the harm having the issue opened indefinitely? It's a constant reminder this is something the community wants