Closed chadly closed 5 years ago
I haven't checked or tried it out, but my first guess would be that in the "incorrect" case, seamless-immutable
, when provided with an array in merge
, merges from the last element to the first. This would cause homer.simpson
to be overwritten with its l33t counterpart. The opposite is happening in the "correct" case since you are making two distinct merge
calls which get called in that order.
Might be a good idea to explicitly call that out in the docs.
@chadly that's strange. I added the following test case:
it("merges arrays with the same result as chained merges", function() {
var expected = Immutable({ username: "homer.simpson", city: "Springfield", kids: 3 })
var original = Immutable({ username: "homer.simpson"});
var toMerge1 = { username: "HoMeR.SiMpSoN", city: "Springfield" };
var toMerge2 = { username: "homer.simpson", kids: 3 };
var actualChainedMerges = original.merge(toMerge1).merge(toMerge2);
var actualArrayMerge = original.merge([toMerge1, toMerge2]);
TestUtils.assertJsonEqual(actualChainedMerges, expected);
TestUtils.assertJsonEqual(actualArrayMerge, expected);
});
and it works and produces the correct result in both cases.
Closing due to inactivity.
Output:
This is perplexing to me as it doesn't seem to merge the username property correctly when calling the array version of
merge
(but it does get thekids
property) while merging the same objects with two separate calls tomerge
works fine.According to the docs, these two should be equivalent: