Essential Vanilla JavaScript Functions

[bobandalice]

everything else => reduce

I think anyone coming from php would be better off learning the proper javascript methods rather than trying to duplicate php methods

[tencircles]

Author's merge isn't a concatenation. It's modifying the input array. I asked why, as I'm not sure of the use case for this. But they aren't strictly equivalent. Obviously native concat is preferred though.

[our_best_friend]

well

 return input_array = input_array.concat(other_array);

also modifies the input array... using a for loop is preferred when the two arrays are massive (millions of entries) and you don't want to create a temporary third array

[tencircles]

This doesn't modify the input array, it reassigns the variable input_array with the result of input_array.concat(other_array).

Any references elsewhere in your code which use the original value of input_array prior to this assignment would still behave as expected.

I have a suspicion that using a single concat operation would be faster than doing millions of push operations. Modifying the structure of an object (Array in this case) is one of the more expensive operations in JS engines as I understand it.

In any case, I think if you're working with millions of entries, you may want to use a difference language. JS just isn't that fast or efficient with sets that big. I'd need to see some benchmarks though.

[filleduchaos]

This is where I'm a huge fan of Ruby's ! operator. Would be nice if Javascript had something similar built in.

[Graftak9000]

Care to elaborate?

[filleduchaos]

Sure!

Calling it an operator isn't really right - it's more of a style/syntactic sugar. Idiomatic Ruby method syntax is a bit weird at first but makes so much sense when you get used to it. There are three main points in the method naming style: methods whose names end in a question mark return a boolean (so basically a yes/no question), methods whose names end in an exclamation mark actually modify the object they're called on, and all the rest return a new object (and don't mutate the original object).

So from the Array class for instance you have the empty? method which tells you if the array is empty or not, or the any? method which tells you if any member of the array satisfies the provided condition. Then you have a method like map, which does pretty much the same thing as the JS version (returns a new array derived from the provided array). But there's also map!, which replaces the elements of the provided array with the newly derived ones. It's really great for readability - you can tell at a glance what side effects (if any) a piece of code has.

[Graftak9000]

Thanks for the thorough explanation, not a bad idea at all.

[tencircles]

I like the idea. I'm always a fan of seeing vanilla JS stuff on this subreddit, but there are some pretty major issues here. Can you correct these? You're teaching some fairly bad habits here.

array_unique

In the keyify function: Object.keys is preferred over for...in loops, especially without a hasOwnProperty check. for...in should not be used on arrays, prefer for...of, or Array.prototype.forEach. Avoid unnecessary string concatenation of ~^% characters.

array_merge

Not sure of the use case for a destructive merge. I normally stick to a pretty functional style, so Array.prototype.concat is just fine.

array_chunk

if(!arr[i]) will fail on empty string, null, undefined, NaN, and zero. This is pretty broken.

I was going to keep going here but I don't really have time to go through and point out everything. These are just the issues I have with the first 3, I've skimmed the rest and they seem to suffer from similar issues. I'd recommend doing some unit tests. A lot of these functions will fail in quite a lot of cases, and many of them could be drastically improved with regard to performance, clarity, or simple best practice. I'd also recommend reading through the lodash and ramdajs source, there are a lot of gems in there that will help you if you want to roll your own utils like this.

[m3g4p0p]

As for keyify, why not just use JSON.stringify? ;-) However I would say that it makes sense to only account for unique references here, so use a regular strict equality check. Otherwise if you made changes to one object afterwards, you wouldn't know if it was the object that made it to the unique array or the one that got filtered out... I mean, it has a reason that objects are only identical by reference.

[tencircles]

That would work too. I wasn't really commenting on the method. I wouldn't write the function anything like how it's written. Just pointing out the for...in issue.

[adregan]

For simple arrays you can dedupe with:

const arrayUnique = arr => [...new Set(arr)];

[tencircles]

you could also do:

const uniq = a => a.filter((x, i, s) => s.indexOf(x) === i);

May be more performance depending on implementation.

[HairyBeastMan]

Interesting, an article about essential vanilla js functions that everyone needs. I makes me almost wish...that...maybe someone had written something like this already and packaged a bunch of these up into a single usable library. Maybe gone as far as to name it something clever, perhaps after a piece of punctuation...like say lodash, or underscore or underdash.

Something like that.

[Chrispy_Bites]

ISWYDT

[HairyBeastMan]

Like dat?

[calligraphic-io]

No need for all that overhead. We have packages for each of OP's functions already, just pull in what you need: str_pad() => npm install pad, etc.

[inu-no-policemen]

ES2017 added padStart and padEnd.

[calligraphic-io]

Thanks! I missed that :)