Onyx.merge does not remove a nested object key

[thienlnam]

If you set an object key to null, Onyx.merge will remove it

Object: {
	transactionID: 12312312
	comment: {
			waypoints: {
				waypoint0: {}
			}
     }
}

This works for first level keys
// Remove all first level keys that are explicitly set to null.

Onyx.merge(key, {
	transactionID: null
}

Corresponding object:

{
	comment: {
			waypoints: {
				waypoint0: {}
			}
     }
}

But if you try to remove a nested key

Onyx.merge(key, {
	comment: {
		waypoints: {
			waypoint0: null
		}
	}
}

It will just set the value to null

{
	comment: {
			waypoints: {
				waypoint0: null
			}
     }
}

[neil-marcellini]

following

[tgolen]

This is very interesting! I didn't believe it at first, but I did a quick test and confirmed exactly what you report. @chrispader you might be interested in checking this one out (our resident expert on Onyx.merge() 😁 ).

[tgolen]

@thienlnam Could you give a little more context into the underlying thing you're trying to do and why it's preferrable to remove the nested key as opposed to having it remain as null?

I could see "consistency" as one argument (and a good one at that), but I kind of feel there needs to be a better reason to change it since it's changing some very low-lying parts of the lib.

[chrispader]

Yes this is indeed a bit inconsistent, but until now this was actually the intended output.

I'm open to changing this so all null values will be removed when merging

[neil-marcellini]

A PR was raised to fix this #350. (edit: oh I think that's just for the type declarations). If top level keys are removed when set to null then we should do the same for nested keys IMO.

[thienlnam]

@thienlnam Could you give a little more context into the underlying thing you're trying to do and why it's preferrable to remove the nested key as opposed to having it remain as null?

Yeah, mostly just an expectation on how merging a null value would work and specifically for waypoints we had the issue because we keyed them like this, and used that to determine the order of the stops / when to add new ones

...
{
	waypoint1: {}
    waypoint2: {}
    waypoint3: {}
}

It just becomes difficult to determine when to add a new waypoint. So for example, if I remove a waypoint it should be

...
{
	waypoint1: {}
    waypoint2: {}
}

But since it doesn't null out, it would be

...
{
	waypoint1: {}
    waypoint2: {}
    waypoint3: null
}

And let's say I wanted to add a new waypoint - I'd have to find the first null waypoint and merge an empty object into it.

And if I deleted multiple stops, it becomes difficult to keep track of - we'd reorder the waypoints and leave all the empty waypoints as waypointX?

...
{
	waypoint1: {}
    waypoint2: null
    waypoint3: {}
	waypoint4: null
	waypoint5: {}
	waypoint6: null
}

In that specific scenario I ran into, it would be nice if we could remove unused nested object keys and I'm sure there are a few other cases that cleaning up the data object would be nice

[chrispader]

I just created a PR for this here. Should be done really soon 👍

[chrispader]

Finished implementation of this feature/bug. 👍

[thienlnam]

Merged!

[thienlnam]

PR was reverted