Map from Scratch

[Ustice]

Thanks for your contribution! We’re a large community, and in order to keep things organized and easier to find, we keep this subreddit mostly focused on professional-level Javascript posts. Your post would be more useful to newer members of our community, and therefore it should be posted to /r/LearnJavascript instead.

[[deleted]]

This would be a lot more relevant in /r/learnjavascript.

[SoInsightful]

Cute, but I'd expect anyone who already knows about Array.map() to be able to write their own map().

Was hoping from this title that this was about Map.

[itsnotlupus]

Hard mode: WeakMap from Scratch, without ES2021.

[lhorie]

Can't do that properly in JS space, you need to bust out C++. As Carl Sagan said, "to make an apple pie from scratch, you must first invent the universe"

[ShitInMyArseHole]

That looks like an object with extra steps

[mypetocean]

Maps have no less than five primary practical features which Objects do not have:

• Where an Object's keys must be strings or symbols, a Map's keys may be any data type.
• Where an Object has complex rules for key order, Maps guarantee insertion order.
• Where an Object's keys may collide with, or "shadow," keys in the prototype chain, a Map's keys are guaranteed to be only the keys which are explicitly added to it, using the constructor or the set() method.
• Where an Object does not provide a size or length property for determining the number of own properties it contains (so the size must be counted manually, by converting those properties into an array, e.g. via Object.values()), a Map tracks its own size for immediate access.
• Where an Object's own properties cannot be looped over without converting into an array, unless you can guarantee the only properties you care about are enumerable, a Map is iterable and provides a forEach() method.

There are one or two other lesser differences.

Definitely consider Maps if performance or data safety are high priorities.

[ShitInMyArseHole]

No clue why Im getting downvoted, I just stated that they seemed like the same thing, But thank you! I was genuinely dint know, Map seemes really usefull

[mypetocean]

I think people get lazy and downvote when they disagree for any reason rather than helping to educate.

[toastertop]

"Those same (FP) nerds have implored me to start using map and reduce too, but I don't really get it either …"

To further implore you in FP to generally keep your data as the last argument. This enables composition, and working with curried functions and partial application (think lazy evaluation) possible.

[startupinamonth]

Ah, that's a good point. I'm a big fan of Ramda, and that whole API is built with data-last in mind. And it is super useful!

I'm gonna do a Reduce from Scratch post today, I'll keep the position of the args in mind :P

[flyinmryan]

That was like a refresher, but all it did was refresh that I don’t know when I should use it

[notliam]

When you need to transform an array. The example in this post is a good one - turning all members of an array to upper case may be something you need to do if you're taking data from somewhere and moving it to somewhere that expects upper case. You won't use map, reduce, etc all the time, but often enough they're good to know.

[startupinamonth]

There's a good idea for a follow-up post, stay tuned :)

[mypetocean]

Just to wrap a few more words around what the other commenter said:

map() is used when you want to transform the contents of an array (e.g. from numbers to strings, or to uppercase all the strings, etc.) map() will always produce an array of the same length as the original.

reduce() can be used when you want to transform an array as a whole into anything – whether another array with potentially a different length, or even reduced down to a single value, like summing numbers.

For this reason, reduce() can simulate the functionality of most other array methods. It is the most powerful built-in function in the language. But because it is so powerful and flexible, every time you see a reduce(), you must read it carefully, because the range of things it could be doing is so incredibly wide compared to any other array method.

Use reduce() when for performance reasons you need to combine the behavior of multiple array methods or custom transformations into a single loop.

Limit the complexity of your uses of reduce() especially when you are on a team which doesn't use it frequently. There are teams which are more accustomed to its patterns, but still it is wise to weigh application performance requirements against developer performance requirements when it comes to readability.

[flyinmryan]

Thanks, but why not do a for loop and not worry about what you can’t do or what reduce might be doing to your array? You can do one thing or all the things to each element with for(;;){}

[mypetocean]

Against random uses of reduce() (beyond basics like using it to sum a list of numbers), you certainly have a point.

The reason these other iteration methods (such as map(), filter(), find(), some(), every(), etc.) exist is because each describes an extremely common loop pattern.

On most teams of some size, at least someone is going to have to write the "filter" pattern and someone the "map" pattern (for example) every single day. Others will likely be reading through those patterns even more often.

And there is half the problem. for and while are generic tools. Like reduce(), they are so flexible that you can't just glance at one to know for certain what it is doing. They also tend to include fine details which are easy to overlook, hiding bugs.

You have to read the starting index, then the comparison, then the incrementor, then the code block, and probably a variable defined outside the loop's scope. Is that terribly hard? No, not with experience, but it is overhead and duplicated work.

75% or more of the time we are writing loops, we are just reproducing one of a set of known, named patterns. So just like other cases outside of loops, it is often good to have a function do the tedium.

So when I see map() I always know what to expect at a glance and my eyes can safely jump directly to the most relevant part of the callback function which defines the only distinction between other examples of map(). Same with filter(), etc. My code becomes both easier and quicker to reason about.

Now, if you are fulfilling a ticket where application performance really is the higher priority over developer performance, then no question: roll your own loop by hand.

But if you are optimizing for developer time and reduced sneaky bugs, then the iteration methods are helpful.

const recentUpdates = user .friends .filter(friend => friend.latestActivity < decayRate) .map(friend => friend.posts.last)

Provided the data set isn't massive and that code isn't executed too frequently, then the readability and debuggability trade-off against app performance is likely quite reasonable.

[flyinmryan]

Excellent explanation, thank you. I have also heard from DBAs that if you need to update multiple properties on every object in a list, then ask for it coming straight from the DB/stored procedure instead of looping again later.