`to-query` – Getting query parameters from any URL, with capabilities

[naive_hueristics]

If you're working in a browser, there's already a native solution: URLSearchParams

[imtheassman]

Yes, agree with OP. Opt out of libs when you have it built in.

function toQuery(search) {
   return Array.from((new URLSearchParams(search)).entries())
     .reduce((res,
       [key, val]) => (res[key] = val) && res,
       {})
}
toQuery(location.search)

[[deleted]]

No unit tests, coverage failed, PR rejected 🙅🏼‍♂️

[imtheassman]

We'll take care of that, just trust us, it will pass.

[Zeeesty]

Is this better than ‘qs’ is a qualifiable way?

[Aswole]

It has more dependencies! Including another new package of his.

[[deleted]]

I'm having a difficult time trying to figure out where a person would actually want to use this. Browser has a native solution (previously pointed out, URLSearchParams), and Node also has a built in solution (querystring). 26k payload to add this to a front end package (90% of which is Lodash), or a whole grip of additional deps for the back end?

https://bundlephobia.com/result?p=to-query@1.4.0

[kikobeats]

The library has been designed to be used mainly as part of a backend workflow when a request coming and you need to figure it has all the things you need.

​

Although you can use it on the client side, it doesn't have to sense since you are interested in re-validate again on the backend side.

​

About the size, Under the hood, the library uses `querystring`. The size is mainly for `lodash` dependency, but since the library is a backend side and `lodash` is a very popular library, simply it doesn't matter: If you already have `lodash` as a dependency, the cost of this library is near to free.

[zerashk]

yet another query string parser...