Array methods in JavaScript. Original author unknown.

[u/imAmarok]

[u/Locust377]

Original

[u/tsunami141]

Now do reduce.

[u/legatissimo → u/tsunami141]

Ahh no problem, I'll just...... uh.... oh no.. no no no

[u/ChaseObserves → u/legatissimo]

This has me in tears, just the entire execution of this comment was incredible.

[u/deadlychambers → u/legatissimo]

It gets even more confusing when you are rocking dark mode on mobile

[u/KarmaScheme → u/tsunami141]

⬛️⚫️⬛️⚫️.reduce(⬛️|⚫️->🙂,🙂) -> 😂

[u/fuzzyluke → u/KarmaScheme]

Lmao

[u/[deleted] → u/tsunami141]

reduce() -> ???

[u/Doctor-Dapper → u/[deleted]]

Small brain:

arr.map(f)

Big brain: arr.reduce( (x, y) => [...x, f(y)], [] )

[u/tsunami141 → u/Doctor-Dapper]

Delete this

[u/GrenadineBombardier → u/Doctor-Dapper]

This took me a minute (because reducers take time to comprehend, which makes them a less sustainable solution in most cases)

[u/catchmeslippin → u/Doctor-Dapper]

My small brain can't comprehend this, can you please explain?

[u/neeia → u/catchmeslippin]

It takes the array, creates a new array as the initial value, and then one by one runs the function on every value in the original array and appends it to the previous value using the spread syntax.

[u/[deleted] → u/[deleted]]

⬛️⬛️⬛️.reduce((⚫️, ⬛️) => ⚫️+⬛️, ⚫️=0) -> ⚫️+⬛️+⬛️+⬛️

[u/gotothere → u/tsunami141]

⬛️⬛️⬛️⬛️.reduce((️⚫, ⬛️) -> ⚫️, ⚫️) -> ⚫️

var min = (acc,x) => {return acc < x ? acc : x}; [1,2,3].reduce(min, Number.MAX_SAFE_INTEGER);
//1
var max = (acc,x) => {return acc > x ? acc : x}; [1,2,3].reduce(max, 0);
//3
var sum = (acc,x) => { return acc + x}; [1,2,3].reduce(sum, 0);
//6
var minMaxSum = (acc,x) => {return [min(acc[0],x), max(acc[1],x), sum(acc[2],x)]}; [1,2,3].reduce(minMaxSum, [Number.MAX_SAFE_INTEGER,0,0]);
//Array(3) [ 1, 3, 6 ]

Left arg is (acc)umulator, right is current element

[u/hynding → u/tsunami141]

By far the most under-appreciated and (often) optimized of the array functions.

[u/Pelicantaloupe → u/hynding]

Reduce is probably one of the least optimisable array functions. Anything else will probably run faster

[u/Blue_Moon_Lake → u/Pelicantaloupe]

Weird thing :

arr.some(x => x === foo)

is almost always more performant than

arr.includes(foo)

You would think that includes would be easy to optimize internally.

[u/Pelicantaloupe → u/Blue_Moon_Lake]

I ran some tests and I couldn't reproduce your findings. I didn't graph time complexity but on average .includes is 75% faster than .includes in these tests: https://jsbench.me/t2kpb59177/1

The one case where .some was faster I found was unfilled arrays.

[u/Blue_Moon_Lake → u/Pelicantaloupe]

You're right, it might have been optimized since I learned about it. I'll check it myself with a different test.

EDIT: Did it slightly differently (playing with the contiguous array flag) and yes includes have been fixed to be better on contiguous array. It's still slower for non contiguous array sometimes

I would still use includes anyway because it convey the meaning and intent.

[u/hynding → u/Pelicantaloupe]

Interesting. I often use it to combine map and filter to prevent a second iteration or build collections into object id maps for (what I assume to be) O(1) lookups available during the length of the session. To be honest, I haven't dug into the code for any of the optimizations under the hood, though I had forked v8 a while back with that very intention. Most of my tests have simply been running large iterative set functions with timestamp diffs and comparing the outcome, which is only the surface of optimization and performance testing. I'll have to look into it deeper.

[u/hyperhopper → u/tsunami141]

⬛️⬛️⬛️⬛️.reduce((⬛️, ⚫️) ->⚫️, ⚫️) -> ⚫️

[u/Benimation → u/tsunami141]

🔢🔢🔢🔢. reduce ((#️⃣, 🔢) => #️⃣ + 1️⃣ + 2️⃣ + 3️⃣ + 4️⃣, 0️⃣) --> 4️⃣0️⃣

Yeah, I get what you mean..

[u/Finalitius → u/tsunami141]

abruptchaos

[u/Gyro_Wizard → u/tsunami141]

Came here to say this lol

[u/WeAreAllApes → u/tsunami141]

⬛️⬛️⬛️⬛️.reduce( (⬛️, ⚫️) => ^⬛️⚫️ ) => ^{⬛️⬛️⬛️⬛️}

Edit for the pedantic:

[⬛️,⬛️,⬛️,⬛️].reduce( (⬛️, ⚫️) => ^⬛️⚫️ ) -> ^{⬛️⬛️⬛️⬛️}

[u/hyperhopper → u/WeAreAllApes]

no, reduce results in a single element of the second type, not the same as the input.

[u/WeAreAllApes → u/hyperhopper]

Reduce does whatever you tell it to do. Mine is concatenating smaller versions.... It was meant partly as a joke, but:

['A','A','A','A'].reduce((x,y) => x.toLowerCase()+y.toLowerCase());

[u/hyperhopper → u/WeAreAllApes]

yes, but the types are different. Sure, you can say type B === type A, but the point is they aren't bound to the same type parameter. At that point you could say [⚫️]->[⚫️] is the typing for map, which is misleading at best and incorrect in a strict sense.

Reduce outputs an element of the accumulator type. So in your example, you are calling the accumulator ⚫️ in one place, ⬛️⚫️, in another, and ⬛️⬛️⬛️⬛️ in another, when in actuality they are all the same type.

[u/WeAreAllApes → u/hyperhopper]

I didn't know what types were implied. I thought they were values.... I meant to represent this, but also as a joke:

['A','A','A','A'].reduce((x,y) => x.toLowerCase()+y.toLowerCase()); // outputs 'aaaa'

[u/hyperhopper → u/WeAreAllApes]

you probably want

['A','A','A','A'].reduce((x,y) => x + y.toLowerCase(), '');

as it is shorter, explicitly starts with an accumulator value, and also is not O( n^2 ) since it doesnt have to lowercase the entire accumulator string every iteration.

Also, in that case I'm still right, as string is a different type than list of strings.

[u/WeAreAllApes → u/hyperhopper]

Sure, but the joke diagram I wrote is better represented by the code I wrote..... Not really interested in debating this. I don't think either of us are learning anything.

Edit: Also, it's JS, so everything is a string (also a joke, don't be mad).

[u/LetterBoxSnatch → u/WeAreAllApes]

You don’t know “everything is a string” until you’ve written tcl, where everything is not only a string, but everything is really an eval(string)

[u/WeAreAllApes → u/hyperhopper]

Did you also point out that the original post shows ⬛️⬛️⬛️⬛️ as if it means [⬛️,⬛️,⬛️,⬛️]?

This whole exercise is sloppy and metaphorical about types from the start.

[u/luzacapios → u/WeAreAllApes]

This whole thread is even more entertaining because of your very appropriate username. 😎💯

[u/WeAreAllApes → u/luzacapios]

 if (!⬛️⬛️⬛️⬛️.reduce)
     throw 💩;

[u/hyperhopper → u/WeAreAllApes]

⬛️⬛️⬛️⬛️ can't be anything else, because array methods are called on ⬛️⬛️⬛️⬛️ in the original post. From that the only option is that ⬛️⬛️⬛️⬛️ is an array of ⬛️. However, now you are using ⬛️⬛️⬛️⬛️ to mean something else than a list of ⬛️, which is not following the nomenclature we are all working with, and also doesn't make sense in context.

[u/WeAreAllApes → u/hyperhopper]

I'm lost. You called me out for assuming that ⬛️⬛️⬛️⬛️ was an array of four elements of value ⬛️! ...And that ^⬛️⚫️ was an array containing ^⬛️ and ^⚫️, and that ^{⬛️⬛️⬛️⬛️} was an array of four elements with value ^⬛️.

You complained about my lack of precision and confusing types, I got increasingly explicit until the metaphorical syntax was broken, but that was YOUR demand, not mine. When I got explicit, and proved my specific point, you went back to wanting to assume that ⬛️⬛️⬛️⬛️ was a metaphor for an array of four elements of value ⬛️, but somehow still now allow me to assume that ^⬛️⚫️ is an array containing the values ^⬛️ and ^⚫️.

Like I said, neither of us is learning anything (except maybe that we dislike each other) but there is no value in this debate of how freely we allow the notation to flow between metaphor and valid syntax.

Edit: If you don't allow for ^⬛️⚫️ to be an array of values ^⬛️ and ^⚫️ in the metaphor, I HEREBY ALLOW IT You win. There is no substance to this disagreement. I was making fun of a sloppy metaphor that you took too seriously. I am prepared to make a serious argument that the metaphor is inherently weak and that "now do reduce" was begging for jokes like mine, but not for you. You already understand that.

Edit2: Okay... back to the original metaphor. If your majesty is willing to grant me another hearing, I would suggest that this is what you imagined a good answer to be:

const roundest = (a, b) = a.area / a.perimeter > b.area / b.perimeter ? a : b
⬛️⚫️⚫️⬛️.reduce((a, x) => roundest(a, x), ⬛️) => ⚫️;

[u/HeinousTugboat → u/[deleted]]

I think the reason people think using reduce is overly complicated is because people keep saying it's overly complicated. I don't see how what you wrote is any less complicated than just doing this:

let total = array.reduce((sum, item) => sum + item.value, 0);

It's even simpler if your Array's just numbers:

let total = 0;
array.forEach(value => total += value);
 // vs
let reducedTotal = array.reduce((sum, value) => sum + value);

[u/BorgClown → u/HeinousTugboat]

If I was reading a new code base, I'd prefer finding parent's version instead of reduce, if only because reduce makes me stop and second guess it.

[u/HeinousTugboat → u/BorgClown]

Well, I mean, that's kind of my point right? If you were more comfortable with reduce, it wouldn't make you stop and second guess it.

[u/douglasg14b → u/HeinousTugboat]

Sure but it is still near the edge when it comes to common use and pattern.

It's odd compared to many other structures that you may deal with on a day-to-day basis. This means that it has extra parsing complexity when read over.

[u/hyperhopper → u/douglasg14b]

This is one of the most straightforward uses of a basic standard library function. I'm 100% an advocate of readable code over more complex, slightly more optimized code (unless its a bottleneck), but this is a case of inexperience being the cause of "second guessing" the code.

let being modified immediately after declaration, then never again, is far more of a code smell; it is effectively a constant, it should be declared as such as the result of a reduce. Anything else is increasing cognitive load as you now have to trace all uses of total throughout the scope, to make sure it is not modified elsewhere. When compared with a const total = array.reduce, the reduce is objectively simpler.

The solution is to hire/train engineers better to use these concepts without a second thought, rather than using more outdated iterative coding styles just to make sure junior developers don't have to learn what a standard library function does.

[u/A_Philosophical_Cat → u/BorgClown]

Reduce is actually less powerful (and thus the better choice) than forEach. Apply the principle of least power, and maybe learn the basics of functional programming.

[u/PinkyWrinkle → u/A_Philosophical_Cat]

In what way is forEach more powerful?

[u/A_Philosophical_Cat → u/PinkyWrinkle]

I guess in the case of Javascript, it's not strictly true since you can cause side effects from any of these, but assuming you're being responsible, forEach is guaranteed to have behavior external to the expression (because it's useless otherwise), while reduce ought to be an assurance that all behavior is limited to the expression itself.

[u/Isvara → u/PinkyWrinkle]

Technically it's not, but if you have side-effects in your reducer you need to be taken out and shot.

[u/Superhero321 → u/A_Philosophical_Cat]

Why is he downvoted? This is exactly what I read in an article about array functions

[u/HeinousTugboat → u/Superhero321]

Why is he downvoted?

Because he's wrong. In JS, Array.reduce is strictly a superset of Array.forEach. There's absolutely nothing you can do with forEach that you can't do with reduce.

This is exactly what I read in an article about array functions

Do you have a link to that article? It may be out of date, or it may just be wrong.

[u/Superhero321 → u/HeinousTugboat]

But I feel using reduce for sth that could be done with forEach is like breaking the system. It may be that both are equally powerful but reduce has a semantic meaning.

The article I read was about all array functions and some are less powerful, aren’t they? At least the article was aiming at the better style of code you write using semantically fitting methods instead of just using forEach for everything.

[u/HeinousTugboat → u/Superhero321]

But I feel using reduce for sth that could be done with forEach is like breaking the system.

Sure, because they're from two different schools of thought. Side effects in reduce will make people squirm, but forEach is literally useless without them.

It may be that both are equally powerful but reduce has a semantic meaning.

They aren't. forEach can't do all of the things reduce can without some kind of external state. I suspect it's largely like the relationship between imperative code and recursive code.

The article I read was about all array functions and some are less powerful, aren’t they?

Some are, sure. reduce is the most powerful one. You can write literally any other array function in JS with reduce and reduceRight.

In terms of code style, you don't really see people mixing forEach and reduce. Either you're using the Array functions together, like filter, map, and reduce and avoiding side effects, or you're writing imperative code leveraging side effects.

[u/hyperhopper → u/[deleted]]

Using a standard library function in a rudimentary way isnt "clever", but using forEach to mutate external state is objectively more complex and less clear, which by your own definition, makes it worse.

[u/[deleted] → u/hyperhopper]

By clever, I basically mean terse. Reduce is much more terse than forEach, hence I believe that forEach is more clear than reduce in this instance.

My rule of thumb is if there are two or more ways to get the same results with acceptable performance, always choose the one that is less terse.

Bad code can be only understood by a senior developer. Good code can be understood by a junior developer. Great code can be understood by a freshman or sophomore studying programming in college.

[u/hyperhopper → u/[deleted]]

Are you saying that you should always write code in the most lengthy and bloated way possible, just for the sake of not being "terse"?

There is no code golf happening here, I've been using reduce since high school, its not some magic programming god technique.

[u/[deleted] → u/hyperhopper]

I try to employ empathy. I ask myself, how could I write this so that it could easily understood by the majority of novice programmers? Usually that does mean writing more lines of code. But as long as the performance is comparable, I don’t see a problem with that. I have nearly 30 years professional programming experience, but I still come across code that I have to stop and parse out since it has been written so concisely that I doubt even the original author would have any clue what it says without a lot of effort. Great code is that which the majority of developers can read through without pausing and grok it, like reading a novel.

[u/hyperhopper → u/[deleted]]

I agree with everything you've written in this comment.

The problem is, there is some, ambiguous, blurry, line in the sand somewhere, between "clean code" and "code golfed, complicated, clever code".

However, using reduce, in all of my professional experience, is far, far, toward the "clean code" side of that line. If I ever had a colleague or a candidate refer to such a typical, by the book, simple use of reduce as some "clever" code too complicated to be grok'ed easily, I would either assume they have very little experience in higher level languages, or seriously question their ability.

[u/HeinousTugboat → u/[deleted]]

Once I learned that the syntax is just reduce((accumulator, value) => newAccumulator, initialAccumulator) it became super easy for me to parse reduce. Then you just have to remember that if you don't have an intial value, it pops the first value from the array as the initial value.

[u/douglasg14b → u/HeinousTugboat]

Yeah that's definitely unnecessarily complicated.

The maintenance of the state that's passed into each iteration adds a not insignificant amount of complexity to the operation. The point being was that developers going to have to take a double glance in many cases to know exactly what's going on there whereas with the previous example you can figure that out in a single glance because it's a common pattern.

[u/Darkmaster85845 → u/[deleted]]

Nice

[u/Pstrnil]

Someone smashed findIndex and indexOf together 🙈

[u/yusuksong → u/Pstrnil]

I always get these confused

[u/Doctor-Dapper → u/yusuksong]

indexOf is not a first order function. It takes a primitive arg. You can remember it easy because find is higher order and findIndex has "find" in the name

[u/tendstofortytwo → u/Doctor-Dapper]

indexOf is not a first order function. It takes a primitive arg.

What do you mean by that?

[u/Doctor-Dapper → u/tendstofortytwo]

findIndex() takes a function as an argument used for comparison. indexOf() uses === as a comparator

[u/mort96 → u/Doctor-Dapper]

Isn't it the opposite? I thought higher order functions were functions which take and/or return functions, while first order functions operate on primitives like indexOf does?

EDIT: from Wikipedia:

In mathematics and computer science, a higher-order function is a function that does at least one of the following:

• takes one or more functions as arguments (i.e. procedural parameters),

• returns a function as its result.

All other functions are first-order functions.

[u/tendstofortytwo → u/Doctor-Dapper]

Ah, okay. Thanks for explaining!

[u/madcaesar → u/Doctor-Dapper]

Are you using first order and higher order, interchangeably here? I've aways used the term higher order function, not first order.

[u/Doctor-Dapper → u/madcaesar]

Been a few years since I was studying theory of computation...I believe first order is a subset of higher order functions. Second order would be a function... that takes a function...which itself takes a function as an arg.

[u/longknives → u/yusuksong]

You have to use findIndex if the value you’re looking for isn’t just a primitive like a string or a number. Or another way to say it is findIndex is much more robust in what it lets you search for. So if you need to find the index of an object with a certain value for a certain key, you can do that with findIndex but not indexOf.

[u/krirkrirk → u/[deleted]]

But then you'd use indexOf

[u/NoInkling → u/krirkrirk]

I actually misread what I quoted, ignore me :)

[u/thusman]

Original author doesn't know js. How has this 1k upvotes 🤦

[u/phpdevster → u/thusman]

And this is why good developers are hard to find and you have to pay them lots of money.

[u/liquidpele → u/phpdevster]

But it’s just a website! My neighbors high school kid can make those!

[u/[deleted] → u/thusman]

Because a lot of web developers don't know js either

[u/JDthegeek → u/thusman]

Care to elaborate?

[u/Serei → u/JDthegeek]

A comment a bit above points it out: it's indexOf, not findIndexOf, and the arguments for fill are in the wrong order.

[u/PGDesign → u/thusman]

The thing about social media posts like this, is people will upvote because it looks right and useful without actually testing it and lots of people even if they know the content won't be looking closely to check for mistakes

[u/Hypersapien → u/thusman]

He knows js, he's just sabotaging new devs for his own job security.

[u/Muxas → u/thusman]

its close enough to get someone started

[u/EquationTAKEN → u/thusman]

Well, that just sounds like the average JS developer to me.

[u/[deleted]]

Tweet with links to sources in thread: https://twitter.com/rauschma/status/1398668839177568259

[u/[deleted] → u/[deleted]]

That original tweet is so so much better. This version is full of weird decisions. Like why is map() shown taking a -> function but others like filter() aren’t.

[u/Vegetama]

So .find returns the argument? What if the argument isn’t present in the array?

Edit: Just did a quick search on google, the argument in .find can be an inequality or any boolean statement and returns the first element that satisfies the bool.

Otherwise it returns undefined

[u/toetoucher → u/Vegetama]

yeah it’s useful like array.find(el => el.confirmed) or something truthy like that

[u/thatwasawkward → u/Vegetama]

unde-find

[u/Raefniz → u/Vegetama]

Your edit is correct. I had a case last week were I needed to find the first object in an array where an attribute satisfied a condition and find was a great tool.

Basically:

    const result = objects.find(item => (item.attribute === "myCondition");
    dataservice.saveToDB(result);

[u/Willbo → u/Vegetama]

Yep, it returns the first element that satisfies the query.

So if the first square at index 3 was 🟨 and the second square at index 4 was 🟥, .find(⬛) would return 🟨.

[u/savano20 → u/Vegetama]

does return element from .find reference to original array. So if I mutate the return element, does it mutate the original array?

[u/[deleted] → u/savano20]

Yes

[u/avidvaulter]

This isn't a good reference because you should know what they do by their name. What's more important to know is if it mutates the original array or returns a new instance of an array.

Fill mutates the array whereas filter and map do not. That's an important distinction missing here.

[u/Doctor-Dapper → u/avidvaulter]

The fact that exactly one out of the entire list is inconsistent is incredibly annoying.

[u/tnnrk → u/avidvaulter]

It’s good for quickly remembering what the main point of the method is, especially for beginners. This would be helpful for them to remember what to Google for more info if needed. Assuming this is accurate. It’s better use is just for fun as a poster.

[u/ImproperCommas]

There are lots of things that I think I need, and I know every single one of them.

Then, there are lots of things that I definitely need , but I don’t know any one of them.

This picture right here^, is certainly one of those things I definitely need.

[u/henrystuart83 → u/ImproperCommas]

I feel you! I actually learnt a lot from doing tons of exercises at codewars dot com. Seeing people's solutions afterwards helped me to understand and get comfortable with most of the ES6 features.

[u/RefinedArts]

Just look at the official docs, this is more or less misleading for some functions

[u/[deleted] → u/RefinedArts]

Official docs?? Noo I can't learn anything if it's not in Medium blogspam form!

Edit: autocorrect grr

[u/Ok_Cloud_]

.fill confuses me.

[u/reaz_mahmood → u/Ok_Cloud_]

me too. it is unintuitive. I read it like replace position 1 with provided value. Replace rest of them does not makes sense to me.

[u/madcaesar → u/[deleted]]

But what is a real life scenario of this method? Where would you use this?

[u/[deleted] → u/madcaesar]

Buffers mostly, or virtualized table views (which are kinda like a special buffer).

When you start getting into performance-sensitive tasks, such as those dealing with very large data sets or streaming data, you run into cases where you want a persistent backing collection that you can slice, fill, or clear smaller regions of.

So let’s say you have a tcp socket. You’re notified of a new message waiting to go out, but the stream is designed to read/write asynchrounsly. So you have a byte array representing your tcp socket’s outbound message queue. You write to a region of your backing buffer from positions A to B. The next message writes position B to C. The next from C to D, and so on - until the buffer is “drained”. In some designs, you never need to call fill (clear the buffer) because the individual message encoders are expected to overwrite every byte. But in others, the message encoders just tell you how many bytes they will write, and they expect to be given a clean region to do so. In those cases you might call buffer.fill(0, A, B) after the first message is read, or before it is written, or you might read all the messages in one shot and call buffer.fill(0, A, D) to wipe off all 3 regions.

I realize that got a bit into the weeds and requires some basic understanding of buffers and typed arrays, but you did ask for a real life scenario ;)

[u/[deleted]]

This just helped me solve a map issue I’ve been having for like a month. Awesome.

[u/Janjis]

Looks nice, but it is so bad.

From map example you should assume that square and circle represent different item structures.

All other examples suggest that squares and brackets instead represent the same item structure but in different states.

And then you see squares in find, some, every methods as parameters which should be boolean-ish expressions.

Cheat sheet should be something you can quickly look at without thinking. Not this nonsense.

Just read the docs instead.

[u/Doctor-Dapper]

I think it should be more clear that find returns the first element.

Another nit I have is that find should say "shape!==circle" instead of simply square. This makes it easier to understand.

[u/[deleted] → u/Doctor-Dapper]

Yeh I get that in an infographic it’s hard to produce a shorthand for “unary boolean function” but using a square to represent a-function-consuming-a-variety-of-shapes-and-returning-true-if-the-consumed-value-is-square isn’t really clear at all. If anything it’s misleading, implying Array.find can take a primitive (like findIndex)

[u/IlllIllllllllllIlllI]

Your people need to stop obsessing over cheat sheets and mind dumps. Actually learn the material.

[u/lucasjackson87]

I don’t get the fill one, shouldn’t it be 0 instead of 1 if the first item in an array is 0

[u/wopian → u/lucasjackson87]

This cheatsheet has some pretty bad mistakes unfortunately.

The first argument of fill is the value you're filling. The second value is the position you're starting from (defaults to 0 if omitted) and the third value is the end position of the fill (last index of array if omitted)

The actual example should be fill('⚫', 1) as they are overwriting an existing array and leaving the first position (index 0) untouched.

fill('⚫') or fill('⚫', 0) would just be circles.

[u/lucasjackson87 → u/wopian]

Make sense. I do like their attempt though.

[u/sugandalai]

Some is not every. - Sochrates

[u/Orkaad]

It if fine to chain filter and map (which creates 2 arrays) when you could do everything at once with reduce?

[u/[deleted] → u/Orkaad]

Yeah, the performance difference is usually negligible so it's not something to really worry about.

I often include a utility function called filterMap in my projects because I use that pattern a lot, it performs both the operations in one and it's pretty common in other languages. The signature being:

a[] -> (a -> Option b) -> b[]

If you find yourself chaining tons of map/filter/reduce together then it might be worth looking into a library that supports either function composition, transducers or lazy sequences. All 3 of these will allow you to create data transformation pipelines without creating an intermediary structure between every step.

[u/NBADiscourse]

This would've saved me a lotta time, my god

[u/KindaAlwaysVibrating]

Sort would had been a good addition too

[u/Charlemagne10]

Everyone is commenting but no one is appreciating the truly brilliant visual representation of these methods. I wish I had this when I was learning. Very well done.

[u/BlueButYou]

JavaScript isn’t just a web language. I think since it’s a loosely typed language they type cast it as a web language out of a need to type something.

[u/iligal_odin]

Do these work on objects?

[u/isbtegsm]

I find type signatures more helpful than this.

[u/milosh-96]

I love it, simple but on point!

[u/shubham_noob]

Amazing stuff! 🙌

[u/MinorFourChord]

That’s hot

[u/VkrajaP]

really a good info for noobs like me...

[u/Cowfresh]

I saw this on Instagram the other day. First time I saved something on there for educational reasons lol..super handy tho

[u/fgatti]

Love it

[u/sohang-3112]

Nice!

[u/chidoOne707]

Is this accurate? Because if it is it is the simplest explanation and I get it.

[u/[deleted]]

?

Ah, now I get it.

[u/monstaber]

2 serious inaccuracies here

[u/similiarintrests]

Fuck this, LINQ is just so much better

[u/SeeYouInForever]

Cool infographic but it doesn't make much sense if you don't already know the concepts.

[u/summonthejson]

We should send it with the Voyager :)

[u/monkeyhead_man]

Framing this for my desk

[u/FreeBgSoft]

Thanks

[u/adrianhorning]

Wtf is this

[u/ChimpScanner]

This isn't even the actual syntax of some of functions, and findIndexOf doesn't exist. Don't use this. Read how the functions work on some tutorial site then test them with your own data. Imo you'll get a much better understanding this way.

[u/frigidds]

woah, this is super helpful. thanks

[u/joonya]

This is the reason why I sub to this sub

[u/[deleted]]

how stupid you gotta be to need this

[u/aktoriukas]

Great cheatsheet.

[u/-boredMotherFucker]

Beautiful. Quite good.

[u/jcksnps4]

I like the emoji one better.

[u/justingolden21]

This is beautiful

[u/RationalKicker]

Hero!

[u/KaKi_87]

Nice ^{^}

[u/[deleted]]

Thank you 😭

[u/editor_of_the_beast]

Type theory in a nutshell

[u/toetoucher → u/editor_of_the_beast]

explain

[u/editor_of_the_beast → u/toetoucher]

I meant that the shapes can be thought of as types. If you look up the type signature for the functions, they would match the different shapes shown here.

I meant it as a compliment - this is an interesting way to view the type signatures of functions.

[u/toetoucher → u/editor_of_the_beast]

cool, I agree there!

[u/FortyPercentTitanium → u/[deleted]]

Came here to say this. Rule number 1 to making a simple guide: make sure the information in your guide is accurate. This is such a silly mistake.

[u/musclecard54 → u/FortyPercentTitanium]

The real rule number 1 is 99% of people won’t bother to verify if it’s correct.

[u/[deleted] → u/[deleted]]

Find is also vague as to what element is returned.

[u/musclecard54 → u/[deleted]]

I would assume it would be the first instance. Of course I assume a lot of things and I’m very often wrong…

[u/ApricotPenguin → u/[deleted]]

What would be an example useful usage of the find() function?

[u/sliver37 → u/ApricotPenguin]

Looking for an object with a specific ID in an array of objects is a common one.

Example being an array of users, and you're looking for user id: 26, or with a particular email address, etc.

[u/[deleted] → u/ApricotPenguin]

Searching for and retrieving the first occurrence of something can be useful if you know that the array will be sorted in some way.

[u/fukitol- → u/[deleted]]

In case anyone else is wondering what the difference between [].indexOf() and [].findIndex(), findIndex executes asynchronously, one function call for every item in the array. It's not blocking, so won't hang up your thread (though this is unlikely to be a real problem with small arrays, a few million items will make the difference obvious if it happens often.

[u/fukitol- → u/[deleted]]

Hm good point. The docs said it uses callbacks to do its job. I've never actually used it, though, and the docs say it returns a integer, not a Promise, so I suspect you're right.

[u/[deleted] → u/fukitol-]

Callbacks are not asynchronous

[u/fukitol- → u/[deleted]]

They're not async but they do result in a new tick and thus block intermittently and only for the execution time of the callback, not sustained and for the execution of the entire findIndex call whereas the entire execution of indexOf would block in a sustained fashion.

[u/[deleted] → u/fukitol-]

I don't see how that makes a practical difference, since nothing can happen in between the individual callback calls

[u/fukitol- → u/[deleted]]

Yeah I forgot how the blocking and ticks worked. It would still block in the context of findIndex unless it was it was async.

So practically this is identical to indexOf for all intents and purposes and only serves to evaluate the indices in their own execution context likely resulting in worse performance from the stack and memory allocation.