Echo JS 0.11.0

<~>

snappo 2508 days ago. link 1 point
more than "what's the point of using this over Object.assign"
my question is
"do we really benefit of yet another dependency that is less than 50 lines of JavaScript ?"
jth0024 2508 days ago. link 2 points
Fair point! Personally, I like to build applications from small, targeted dependencies that do one thing well, but it's fine if you don't find that approach or this library useful. I didn't see anything quite like it on NPM, and I only posted it on the off-chance that someone else might find it useful.

P.S. I'm sure I could re-write it to be more than 50 lines if you'd like.
Balkoth 2508 days ago. link 1 point
What's the point of using this over Object.assign ?
jth0024 2508 days ago. link 1 point
Good question! Well, Object.Assign overwrites any previous properties without discretion. For example, Object.Assign({ name: 'Greg' }, { name: 'Fred'}) will result in { name: 'Fred' }. That behavior isn't ideal when you only want to apply default values for missing arguments, a common task in my projects. Essentially, this library is offering a customizable Object.Assign. You can use the default customizer, which only overwrites null or undefined values, or you can write your own customizer that implements any logical check that you choose.
xat 2508 days ago. link 2 points
The way Object.assign is usually used is like this:

const opts = Object.assign({}, defaults, options);

It will fallback to the properties defined in defaults if they don't exist in options.

Nowadays you can also use destructering to achieve the same:

const opts = { ...defaults, ...options };
jth0024 2508 days ago. link 1 point
Yep, that's a great way to use Object.assign, but that doesn't really cover the variety of cases that prompted me to write this helper. For example, your code only works if options does not have a key for the default value, but not when it has a key with a null, undefined, or otherwise unacceptable value. const defaults = { name: '' }; const opts = { name: null }; Name would be set to null, which is a common case I try to avoid.
xat 2508 days ago. link 1 point
If someone explicitly passes in "const opts = { name: null }" then I would argue that he wants name to be null and it should not be overwritten by what is defined in defaults. But I agree with you that there may be some (rare?) cases where some other behaviour is wanted.
jth0024 2508 days ago. link 1 point
Well, I can't speak for the needs of every other developer or application, but I have personally encountered plenty of cases where null and undefined checks are necessary to avoid runtime errors.
planttheidea 2508 days ago. link 1 point
Based on your use of isNil, you consider null to be an invalid value, not just undefined? Is there a reason you differ from the spec?
jth0024 2508 days ago. link 1 point
Good question! I assumed that most people using this library would use it to handle missing arguments in their functions. Based on that common use-case, I expect that null and Undefined are both considered "missing" arguments. That being said, I anticipated that this might not work for every use-case, so I allow you to write your own customizer if that behavior is not ideal.
xat 2508 days ago. link 1 point
You can check for the existence of a property with obj.hasOwnProperty('someProp').
jth0024 2508 days ago. link 1 point
Yep, you can. But like I said, if I were only hoping to apply default values for missing properties I would just use Object.assign like others have suggested. Instead, I wanted the ability to use any conditional check that I choose when merging values, and I wrote this library because I've frequently needed to write little wrappers that used Object.assign to do that. It's useful to me because it provides an easy way to perform common tasks with less code. I didn't write the library because I'm unfamiliar with ES2015 or the Object API.