Support for ImmutableJS setIn array paths

[Reanmachine]

Problem

ImmutableJS's setIn (and thereby updateIn / deleteIn / etc...) do not seem architected to work with a mixture of Map and List objects. The call assumes that an "unset" value can only be one thing, and only has one resolution path for when that value is empty. (Namely, add it as an empty map) See Immutable-js Source

This leads to the issue found in #1574 where we get the infamous error:

Uncaught TypeError: list.splice is not a function

When using immutable-js with FieldArray. The focus / blur events are calling setIn on fields.fieldName[0].touched etc... which causes the fieldName part of the tree to be instantiated as Map instead of a List.

Actual	Expected
{ "fields": { "fieldName": { "0": { "touched": true } } } }	{ "fields": { "fieldName": [ { "touched": true } ] } }

Solution

We need to pre-seed a mixed type path like fields.thing[0].visisted with empty List objects at each array breakout point. This allows immutable to simply update the existing List with a call to set() instead of trying to instantiate it as a Map

I have broken the structure/immutable's setIn method out into it's own file to allow us to take some liberties with it.

Extra

Along with this PR I've included regression tests for the setIn behaviors I fixed as well as some tests for some of the expected vanilla setIn behavior the library depends on.

[codecov-io]

Current coverage is 100% (diff: 100%)

Merging #1716 into master will not change coverage

@@           master   #1716   diff @@
=====================================
  Files          52      53     +1   
  Lines        1115    1134    +19   
  Methods         0       0          
  Messages        0       0          
  Branches        0       0          
=====================================
+ Hits         1115    1134    +19   
  Misses          0       0          
  Partials        0       0          

Powered by Codecov. Last update 9186bd3...cf0a18c

[erikras]

Published in v6.0.3.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.