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 ?"
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.
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.
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 };
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.
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.
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.
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.
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.
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.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 };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.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.You can check for the existence of a property with obj.hasOwnProperty('someProp').