Option to not throw TypeError for null or undefined targets

[sindresorhus]

Option to not throw TypeError for null or undefined targets

[jbellsey]

This is confusing me, and causing my app to crash.

I understand the choice to not allow root-level null targets (e.g., deep_assign(null, {a:1}). However, I would expect to be able to assign to null values inside an object without throwing an error:

deep_assign( {a:1, b:null}, {b:99} )
// error

The library will reject assignment to any key that has a null value, regardless how deep it is in the structure.

[whizkid77]

I'm currently using lodash's _.merge() for a similar use case.

[sindresorhus]

"Note that Object.assign() does not throw on null or undefined source values."

It says source values, not target. This module behaves the same as Object.assign. Target must be an object, but sources can be anything.

Object.assign(null, {});
//=> Uncaught TypeError: Cannot convert undefined or null to object(…)

[whizkid77]

I'm seeing this in node v5.3.0:

> var deep_assign = require('deep-assign');
undefined
> deep_assign({foo:null},{foo:'bar'})
TypeError: Cannot convert undefined or null to object (foo)

> Object.assign({foo:null},{foo:'bar'})
{ foo: 'bar' }

[schnittstabil]

@whizkid77 In my opinion that is the expected behavior, because we Recursively Object.assign():

deep_assign({foo:null}, {foo:'bar'})

// should be similar to
{foo: deep_assign(null, 'bar')}

// which have to be the same as 
{foo: Object.assign(null, 'bar')}

[whizkid77]

Ah that's another way of looking at it. Either way is fine with me, but it should just explicitly be noted that this is the case in the readme. However, it would mean that deep-assign cannot be a drop-in replacement for Object.assign, and therefore limiting its usefulness (to me, anyway).

[schnittstabil]

deep-assign cannot be a drop-in replacement for Object.assign

Maybe sindresorhus/object-assign is what you seeking for.
Unfortunately, we can not do both: a (non-recursive) drop-in replacement for Object.assign and recursively Object.assign 😉

To sum it up, the current behavior is:

deep_assign({foo: 'foo'}, {foo: 'bar'})
//=> {foo: 'bar'}

deep_assign({         }, {foo: 'bar'})
//=> {foo: 'bar'}

deep_assign({foo: null}, {foo: 'bar'})
//=> TypeError: Cannot convert undefined or null to object (foo)

deep_assign({foo: undefined}, {foo: 'bar'})
//=> TypeError: Cannot convert undefined or null to object (foo)

[ruffle1986]

For the first time, it confused me as well, but if you strictly see the definition of Object.assign and recursion, you can see that @schnittstabil is right.

I'm afraid it prevents deep-assign from being a successful module because it's hard to understand the point at first. As I see most of the people look at deep assign as a deep-extend function which is incorrect.

[schnittstabil]

@jbellsey As Object.assign does not allow that, I see currently no justification to do so in deep-assign.

However, I'm always looking for real world examples, which allow us to reconsider the current behavior. May you share your use case with us – just a tiny snippet, e.g. a use case of your library function?

[jbellsey]

Fair enough; I will fork or find another solution.

My situation is this: the API returns a user record, which I cache locally. I poll the server for new data, and merge that into the local user record.

And (you saw this coming) the server sends fields as null when there's no data.

// first poll:
user = {
  device_features: {
    locked: null,     // here comes trouble...
    pin: '1234'
  },
  settings: {
    email: '[email protected]'
  }
};

// poll for new device status, which should be merged into the user record:
new_device_data = {
  locked: true,  // in some cases, this is an object; any non-null value fails
  pin: '1234'   // this field is sometimes not included; we only get changed values
};

// here's where we error:
deepAssign(user.device_features, new_device_data);

This breaks my mental model. It makes sense to error if the target itself is null, but not if a property somewhere inside the target is null. That, to me, is a very abstract notion of applied recursion...recursive algorithms always allow for a special case at the margin.

Again, your library, your call.

[schnittstabil]

@jbellsey Thanks for sharing, things are complicated as that is only one use case, so that would take some time – as an interim solution you may give merge-options a shot – but there a countless similar packages out there.