Discussion on: 👋 Say Goodbye to Spread Operator: Use Default Composer

View post

For all the devs using lodash:
merge & mergeWith is doing the similar thing

Thank you for sharing @renekaesler. At first we got the same functionality with mergeWith:

In the end we opted for our own implementation to avoid 10kb, even though we were importing only mergeWith and not all lodash we thought it was too much for this feature.

This is the current implementation:

github.com/aralroca/default-compos...

René Kaesler • Jun 6 '23 • Edited

Thanks for sharing your lib to the community, @aralroca !

Got your point! But 10kb for a single method import sounds strange. Just being curious: Have you used the lodash-es package?

All in all it's not about lodash. It's just about the hint: Widely used utility frameworks may already have this functionally available 😊

Jeric Bas • Jun 13 '23 • Edited

Nah! Avoid lodash merge and mergeWith.

Lars Rye Jeppesen • Jun 6 '23

No dev should be using lodash

René Kaesler • Jun 6 '23 • Edited

Hehe, okay okay!

I had not planned to trigger a framework debate. I'm sure your preferred FP-utility framework is capable of the merging concept, too. No matter if it's ramda, underscore or whatever else exists.

insidewhy • Jun 6 '23

What's the reason? With lodash-es and a tree-shaking bundler I only pay for what I'm using, so I don't see the harm in importing a few functions from lodash if I need them.

Mateus Amorim • Jun 8 '23 • Edited

lodash has bad types in general, destroying typesafety and can be easily overused, creating very ugly code that is hard to understand unless you are really familiar with it. Many of the things it does can easily be done with native javascript too.

ofc, you can still use it for some things, and you can wrap it with functions with better typings, but in general it is good to avoid using it at all when working on teams since others might overuse it or use it in an unsafe manner.

something that is commonly oversued is the lodash "get" method, ex:

_.get(a, "b.c", [])

this has many issues:
1 - the second parameter is not typed, so we don't know what we can access or if it exists or not
2 - the third parameter is not restricted to the type of a.b.c
3 - the resulting type is "any", making it easy to do typeErrors.

Nowdays we have better alternatives in general, for example:

a?.b?.c ?? []

this will solve all of the issues mentioned before and doesn't rely on a library for it :D

Adrien Denat • Jun 9 '23

And there is Remeda!

insidewhy • Jun 9 '23 • Edited

I agree with that, there's bad stuff in lodash for sure (I never use get so it's good you point out the problems with it), but there's okay stuff too.

Mike Thai • Jun 6 '23

Why not? I think lodash is totally fine if you use it efficiently and understand what it does.

But if you're one of those devs who imports the entire library into every project to only use like 2% of it and don't know how any of it works/are completely helpless at your job without it, then yeah I agree - you're just shooting yourself in the foot.

Lars Rye Jeppesen • Jun 6 '23

Because lodash is not maintained as a project any longer afaik

twiddler • Jun 7 '23

github.com/lodash/lodash/issues/5605

aneesshameed • Jun 7 '23

Lodash is a matured library. Because its not updated, that doesn't means that it cannot be used on projects. Lodash works and it helps to write clean code.

Christian Baldwin • Jun 8 '23

Our definitions of clean code are obviously different.

My definition of clean code is thoughtful composition of logic and data in order to avoid needing to depend on 3rd party libraries to help you maintain it.

Denny Christochowitz • Jun 8 '23

🤣

aneesshameed • Jun 7 '23

merge and mergeWith is not doing what this post is about. Completely different

René Kaesler • Jun 8 '23 • Edited

I should have given an example. Normally I am using the following pattern, for default nested options:

const options = {
  b: 2,
  c: 3,
  nested: {
    e: 5,
    f: 6,
  },
};

const defaultOptions = {
  a: 1,
  b: "two",
  nested: {
    d: 4,
    e: "five",
  },
};

// this mutates `defaultOptions`:
const composedOptions = _.merge(defaultOptions, options);

// this preserves `defaultOptions`:
// const composedOptions = _.merge({}, defaultOptions, options);

console.log(composedOptions);
// => { a: 1, b: 2, c: 3, nested: { d: 4, e: 5, f: 6 }}

If you want to tweak the behaviour of value replacement differently for some values, you can use mergeWith. It's quite similar what the library is accomblishing.

Thai Pangsakulyanont • Jun 8 '23

Did you mean defaultsDeep?

npmjs.com/package/lodash.defaultsdeep

René Kaesler • Jun 8 '23

No, I really meant to use merge (see my comment before).

But your hint is semantically even better! 🥳
Didn't know about defaultsDeep

Phylis Jepchumba • Jun 6 '23

Welcome to the community, René Kaesler! We're thrilled to have you here. It's always exciting to see new members join, bringing fresh perspectives and ideas. Feel free to explore the various discussions, ask questions, and share your knowledge with others. Don't hesitate to reach out if you need any assistance or have any specific interests within the community. We're here to support each other and learn together. Once again, a warm welcome to you, and we look forward to connecting with you further. Happy participating!

Maximilian Lenhardt • Jun 24 '23

At least I encountered memory leaks using lodash methods and it's not maintained since 2018 or so.