>>>

>>>$scope.matrixAttributesChanged = function (rowId, columnId) {
...
>>> if (inventorySaveCheck()) {
>>> $scope.form.editRetailForm.editRetailMatrixForm.$setPristine();
>>> let clone = Object.assign({}, $scope.currentIitem);
>>>
>>> changedInventoryObjects.push({
>>> index: key,
>>> inventoryObject: clone
>>> }); // make collection of changed matrix inventory objects
>>> }
...
>>> }

>>>
>>>Does it look like OK implementation?
>>>
>>>The question I have - if I found my item in collection already, I want to replace my current object in collection with the more recent copy of it. What would you suggest?
>>
>>splice().
>>
>>Looks to me that, if currentIitem is meant to point to an existing item in a collection, then '$scope.currentlitem = results' will break that assumption?
>>

>That's why instead of just pointing I am making a clone of the object when adding to the collection of changed objects. So, suppose we got the object originally, changed it, opened another object, changed it too, then tried to look at the first one and made more changes to it - now I need to replace that. The way I currently do it is finding that object in array, make a copy of my current row (clone) and then just use the assignment to replace with that copy.

Just a wild thought: how about using JS prototypal design to avoid cloning/walking through property list ?
Any assignment to property will land only in the prototype-cloned level and the original "row object" is unchanged.

Edge cases clearly refresh/update actions on original row not caring about changed object instance, which would "bleed through" to any unchanged properties - which might even be beneficial, depending on your style of validation, but needs to be thought through at fwk level.
Also any tricks via property definition (esp. enumerability) needs to be rethought, also ratio of property reads vs. cloning operations ;-)

But Object.assign() level of copy/clone might be similar enough to assigning prototype. Reading properties might be minimally slower, as each unchanged property is accessed at once removed prototype level, but such access should be highly optimized at JS implementation level, as it is one of the basic tenets of JS object orientation.

The cloning step could be dramatically faster for objects with oodles of properties, even if object.assign() working through enumerables at C-level speed is much better than iterating properties at JS level ;-)))

A side benefit COULD be the easy way to decide via .hasOwnProperty() which properties were changed on a record if you want to generate update statements only for changed properties. Not mentioning the vfp option of adding prev values to where clause (which could be done as well), as I personally think this way is not the best way compared to the option of record timestamps or record specific write-action consecutive numbers.

untested from the hip:

oRows [{rowId:1, value:"Proto"}, {rowId:2, value:"typal"}, {rowId:3, value:" Level"};
oCha1 = Object.create(oRows[0]);
alert(oCha1.value);
oCha1.value = "Cloned";
alert(oCha1.value);

oEdge1 = Object.create(oRows[1]);
oEdge2 = Object.create(oRows[2]);
alert(oEdge1.value + oEdge2.value);
oEdge1.value = "Changed! "
alert(oEdge1.value + oEdge2.value);
// conceptually similar to a vfp cursoradapter.Refresh()
oRows[1].value = "Refreshed ";
oRows[2].value = " at DB level";
// bleed through in oEdge2
alert(oEdge1.value + oEdge2.value);



@Viv: pls verify my somewhat sunday hung-over/out of blue idea by clear thinking ;-)