21–30 of 46 posts
I would have come up with something like this: Object.entries(Array.from(new URLSearchParams("foo=1&foo=2&foo=3&blah=a&blah=b").entries()).reduce((a,[k,v]) => ({ ...a, [k]: [...a[k] ?? [], v] }), {})).map(([key, values]) => `${key}=${values.join(",")}`).join("&");
I enjoy reading people's off-the-cuff code golf stuff and usually learn something.
Earlier quoted context omitted.
This is a funny quote. I really hope it doesn't keep people from learning regular expressions, which are actually not as hard as they are often portrayed and extremely powerful and efficient, as demonstrated in this post.
Sure it's powerful and a lot of them are easy. But there's a lot of indecipherable regexes in the wild. I guess you need to learn them anyway, but I'm very strict about using them in production
The alternative is what, a simple tokenizing parser? I think that's actually a step squarely into territory of making it more complex and less readable than a simple regular expression is.
Just use match instead? Why use replace and hack into an array? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
To not create a intermediate array I think
[...paragraph.matchAll(regex)].reduce((q,[kv, key, value]) => { q[key] = (q[key] ? q[key] + `,`: ``) + value return q }, {})
> Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. Jamie Zawinski
It's well-adopted (unless you have to support IE: https://caniuse.com/?search=URLSearchParams>)
Just use match instead? Why use replace and hack into an array? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Earlier quoted context omitted.
To not create a intermediate array I think
This works fine: [...paragraph.matchAll(regex)].reduce((q,[kv, key, value]) => { q[key] = (q[key] ? q[key] + `,`: ``) + value return q }, {}) https://pastebin.com/yb5QBCm6
With that said, there could easily be an array being iterated under the hood with the `replace` method anyway.
Please give me an 80 kloc project full of this kind of smartness, preferably minefied.
look at jQuery... if you have never read the source for it, as a developer, you are doing yourself an injustice. not only has john resig worked on it, but also yehuda katz, so there are some really smart people who coded it to learn from.
contains = hasCompare || rnative.test( docElem.contains ) ?
function( a, b ) {
var adown = a.nodeType === 9 ? a.documentElement : a,
bup = b && b.parentNode;
return a === bup || !!( bup && bup.nodeType === 1 && (
adown.contains ?
adown.contains( bup ) :
a.compareDocumentPosition && a.compareDocumentPosition( bup ) & 16
));
} :
function( a, b ) {
if ( b ) {
while ( (b = b.parentNode) ) {
if ( b === a ) {
return true;
}
}
}
return false;
};Earlier quoted context omitted.
look at jQuery... if you have never read the source for it, as a developer, you are doing yourself an injustice. not only has john resig worked on it, but also yehuda katz, so there are some really smart people who coded it to learn from.
In my opinion, having read parts of jQuery's source code on various occasions… You should only read it for entertainment value, it makes for fascinating brain teasers. Here's one snippet I had the opportunity to read recently: contains = hasCompare || rnative.test( docElem.contains ) ? function( a, b ) { var adown = a.nodeType === 9 ? a.documentElement : a, bup = b && b.parentNode; return a === bup || !!( bup && bup.…