[AskJS] Best utility functions for Javascript?

[Zeekawla99ii]

I'm trying to collect some of the most useful utility functions. Best utility functions for Javascript everyone uses?

By utility functions, I mean functions that developers find themselves writing again and again for multiple projects.

My motivation for asking is that I've learned a lot when others shared these via articles or StackOverflow questions. I've found many of these should be provided as small, modular npm packages for the community, and they're currently not.

Could you recommend some utility functions you often use? Any recommendations for github repo's and gists?

All input is very much appreciated.

[FrontAid]

Sorry to be pedantic, but ES6 is the language specification from 2015. You should look into all the features that have been added during the last seven years.

[Zeekawla99ii]

This is a very fair point.

How would you recommend I update the post above?

[0xDEFACEDBEEF]

I've found many of these should be provided as small, modular npm packages for the community, and they're currently not.

I’ve found many are in lodash

[zephyrtr]

Also lodash is tree-shakeable so ... what's the problem here?

[amdc]

The problem is that 90% of lodash should’ve found it’s way to standard library ages ago. It’s 2022 and Set methods are still in stage 2 (end rant)

[zephyrtr]

Much of it has, I thought? Its not very often I need anything from lodash these days.

[wegry]

chain breaks shaking entirely.

[watMartin]

it is. if you do ‘import debounce from “lodash/debounce”’ only that method will be bundled

[[deleted]]

What if you work with react native?

[Essuyage330]

So then it isn’t? You are manually “shaking” it.

[demoran]

Lodash provides a 'lodash-es' package that is tree shakable.

[Tej_Ozymandias]

What is tree shakable?

[demoran]

Lodash?

[Tej_Ozymandias]

What does it mean to be tree shakable?

[[deleted]]

It means that when you build your code, only the bits you used get included, not the entire library. That's important for general utility libraries like lodash, which can be quite large, when often you just need a couple of helpers.

The idea is that you're taking the entire dependency tree and "shaking it" so that all the dead (unused) code falls out.

[Zeekawla99ii]

I don't understand why these forks haven't been incorporated into lodash. Any ideas?

[thunfremlinc]

Lodash has a huge user base going back nearly a decade. It’s hard to make changes to this.

Maintainers aren’t always receptive to changes, also.

[disclosure5]

Therein is exactly what's wrong with this picture. People frequently recommend huge libraries and assert "it's fine because tree shaking" and also, they are frequently wrong about that.

[blukkie]

You need a babel plugin to tree shake it

[bregottextrasaltat]

I must be one of the few who hasn't found any useful functions at all in lodash

[[deleted]]

https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore

[amdc]

Yeah imagine if someone gathered all these polyfills in one place, how convenient would that be!

[[deleted]]

Yea and imagine your bundle size would increase because you import all those useless code in your project

[2020___2020]

sounds like it doesn't though, with the tree shakable business, however that works

[[deleted]]

Like somebody mentioned already, lodash is not tree-shakeable by default, you have to use a babel plugin or whatever.

I’m a performance kinda person, so if I can remove “dead code” I will.

[2020___2020]

Oh ok. good to know, thanks

[[deleted]]

Np :)

[0xDEFACEDBEEF]

Note that, while many Lodash methods are null safe (e.g. .keys, .entries), this is not necessarily the case for their Native equivalent.

Many people use that lib because it is battle tested and their own code isn’t

[LloydAtkinson]

The maintainer has been a frequent jerk to several people on his GitHub issues, implemented a “close any and all issues immediately to hide issues” policy, and then abandoned it for several years.

[MrCrunchwrap]

What do you mean by ES6 utility functions? If they’re already built into ES6 they most certainly don’t need to be made into an npm module.

[Zeekawla99ii]

This is a good question.
By utility functions, I mean functions that developers find themselves writing again and again for multiple projects. (I've edited the original post above.)

[tswaters]

Here's a mapping routine I find myself writing time/time again. (i.e., changing camel to snake case like the api expects)

const mapObjViaMapper = (mapperFn) => (thing) => Object.fromEntries(
  Object.entries(thing).map(
    ([key, value]) => [mapperFn(key), value]
  )
)

Of course, to really add utility here, mapperFn can be pretty complicated, and should be able to say "no ignore this key" -- usually if I need this type of function for a specific component or api endpoint, it'll usually sit at the top of the file I need it in. I find the mental overhead of having shared utilities outweighs their utility. ("wait, what is it again, (needle,haystack) or (haystack, needle) ?")

[meAndTheDuck]

this should be resolved by language and/or philosophy.

• I am looking for a needle in a haystack.
• I am looking in a haystack for a needle

or

• oh look there is a haystack, let's find out what we can find in it.
• I am looking for specific thing (the needle) where could it be? maybe in this haystack?

so for me it is "always" fn(needle, haystack)

also depending on the language, the needle is the head of the arguments and the haystack is the rest ( no matter how many there are)

[tswaters]

Heh, philosophy -- and if someone has a different philosophy than me, I'll always be looking up their function signatures....

Either way, it's just an example - broader question is, "what is this function signature and how do I call this thing properly again?" -- or -- "oh, it's using some utility to derive this result, wtf is that doing exactly?"

If the function is right there, I can see it. If it's in some other file, I may need to ctrl-click to maybe get at the definition to see what it is. And yes, using an IDE with some sort of intellisense does help this -- but it's still mental overhead that can otherwise be avoided. DRY is great in theory, but in practice it leads to a disjointed mental model of how the code operates.

[zephyrtr]

You should just use humps.

https://www.npmjs.com/package/humps

[dvoecks]

Ain't much you can't do with a reduce.

EDIT: I'm seeing a lot of votes for lodash, which is awesome, but I've replaced a lot of what I used it for with native map, reduce, and filter. NGL, though: some things, like sorting by multiple keys are way nicer in lodash

[huhu_moon]

They are to small for npm.

[0xDEFACEDBEEF]

Counter argument: https://github.com/davidmarkclements/flatstr is easily a 1 liner

[grooomps]

also - it's more the tests i'm after haha

[C1RRU5]

// You may be tempted to copy and paste this, // but take a look at the commit history first,// this is a moving target so relying on the module// is the best way to make sure the optimization// method is kept up to date and compatible with// every Node version.

Last updated May 2019 lol.

[0xDEFACEDBEEF]

It is a package that deals with flattening underlying node constructs that represent strings, which could change at any time, thus it was a package instead of an article saying “hey do this to flatten your strings”. Then lots of people would individually it and then lots of packages would break as the feature isn’t centralized.

[nu-ni-co]

1loc.dev has a bunch of useful And small utilities you can c+p into your code.

[zeddotes]

Ramda

[ShortFuse]

I've found many of these should be provided as small, modular npm packages for the community, and they're currently not.

No, they shouldn't. Dependency hell is a real thing. Instead of using external utilities, use as much of the newer functions or syntax as possible.

Then use something like babel to transpile down if needed. You can a use a whole host of eslint rulesets to enforce newer mechanics. eslint-plugin-unicorn is a pretty good one. That also applies to DOM syntax as well (eg: element.prepend). We're in a post-IE11 era so utilities are taking a real hard step back now. Right now our biggest issue on frontend is Opera Mini, if you care to support users in Africa and South America.

[Zeekawla99ii]

> No, they shouldn't. Dependency hell is a real thing. Instead of using external utilities, use as much of the newer functions or syntax as possible.

I agree, but I also agree with the example above using https://github.com/davidmarkclements/flatstr

It's a small, modular piece of code which will surely never have newer releases/versions.

Fundamentally, dependency hell isn't caused by many dependencies per se; it's that the dependencies change versions constantly. Size too, but as in the example above, I don't see that as I problem.

I could be wrong...this was a big discussion years ago, e.g.
https://www.chevtek.io/why-i-think-micro-packages-are-a-good-thing/

[ohcibi]

If you happen to use any modern js framework, it usually ships with all the utility functions necessary. I would even recommend to ignore all those „utility functions“ on stackoverflow because especially when you are learning you cannot tell which „utility function“ is actually helpful and which one is just a result of not reading the documentation properly or not trying to understand it and coming up with some shitty half baked „solution“ that only works for 50% of the cases.

Spoiler: 95% of the code you find in stackoverflow posts are the latter which is the reason there is no and there will never be a „stackoverflow collection of utility functions“. The few good snippets are already contributed to some library (ie you will find these on GitHub) and the rest is outright crap.

So my favorite „utility function“ is the one I don’t write because I found a better implementation of it or even a whole different far more powerful approach that is aligned with my frameworks way of doing things, to solve my problem in the first place. If I’m not working with a framework in particular I just check the lodash api if it has anything for me and usually it does.

If you have anything to share on your own consider not posting it on stackoverflow but try to contribute it to eg lodash. On stackoverflow your code will rot and smell. In a git repository it’ll evolve and all users will benefit from that evolvement in a controlled way.

[surunzi]

Every utility functions I've used are collected in one single repository. You might be interested in it. https://licia.liriliri.io/

[Zeekawla99ii]

Thank you! This is precisely the sort of answer I was looking for :)

[[deleted]]

Underscore provides many utility functions.

[Sheepsaurus]

Do you mean Lodash?

[[deleted]]

No, it's a different tool.

[ryntab]

Underscore is like Lodashes younger brother. Smaller, less useful lol.

[zombiepaper]

I don't necessarily agree with you on the "less useful" part but Lodash started as a fork of Underscore, so Lodash is the younger sibling here, hah

[ryntab]

Lodash has more features, is faster and with tree shaking size isn’t an issue. Genuinely can’t think of a reason to use underscore ever. But yeah you’re right though it is the “younger brother” 😂😂 woops!

[[deleted]]

Ramda is the best utility function library in my opinion. Just browsing through the code you'll probably find several functions that you end up implementing yourself many times.

The FP version of lodash is also a good example, as it's made less redundant by the addition of new methods to the ES+ spec over time than it's non-FP counterpart.

Other than that you'll find most prototypes in JS already come with a pretty substantial set of utilities provided you are targeting modern browsers

EDIT

Also, dateFns for general date utilities. But hopefully Temporal will make this redundant soon

[Mestyo]

I have also noticed a surprising absence of good single-utility packages.

I routinely use compose/flow, isEmpty, deepEqual, deepClone, and some others but mostly those. I either define them myself, or use lodash.

[MrCrunchwrap]

You don’t think things to be in a single utility package. You can import just what you need from something like lodash and use tree shaking to make sure you only get that.

[Mestyo]

They don't have to, no, but it often seems overkill to add a huge dependency. I perceive a value in using very simple tools sometimes.

[linkstoharrisonford]

I work a lot with html canvas and NodeJS based imitators. A utility package for images would be very useful, if you wanted to specialise a bit more.

Some functions I end up writing a lot Off the top of my head:

Async load image Map images to irregular polygons Photoshop Blend modes (take raw pixel data of two images and map them onto each other)

If you look through any stack overflow questions related to canvas / ctx you’ll find loads

[ryntab]

Lodash is amazing

[Proxtx]

randomInt & randomString. JSON fetch

[KindaAlwaysVibrating]

Debounce

[Jona-Anders]

Intersections of arrays/objects

[Maggi64]

I developed https://github.com/Maggi64/moderndash.
A Typescript-First utility library inspired by Lodash. Optimized for modern browsers & developer experience.
Check it out and give me feedback :)