Fractal Store behavior on array properties

[SilverSN95]

This is a...

• feature request
• bug report
• usage question

What toolchain are you using for transpilation/bundling?

• @angular/cli

Environment

Angular Version: 5
@angular-redux/store version: latest
@angular/cli version: 1.5.2

Expected Behaviour:

Using a fractal store on a property of Array type should return updated state as an Array type.

Actual Behaviour:

The new state is returned as an object map where the key is the array index of the object from the original array.

Additional Notes:

Our configuration is almost identical to what is outlined in the fractal-store documentation, but instead of 'users' being an object map using a userId key we are using an array and the array index to access the object. Is this an incorrect use case?
Specifically, the transformation appears to happen in the setIn function. I think this test may demonstrate what we are seeing:

  fit('performs a deeply nested set correctly without mutation', () => {
    const original = {
      a: 1,
      b: {
        c: []
      }
    };
    const expected = {
      a: 1,
      b: {
        c: [{ d: 2 }]
      },
    };

    expect(setIn(original, ['b', 'c', 0], { d: 2 })).toEqual(expected);
    expect(original).toEqual({ a: 1, b: {c: []} });
  });

[e-schultz]

Hi, you are correct - the current version of set-in is not expecting to handle updating paths within an array.

Getting it to handle ['b', 'c', 0] should be pretty easy, although for things like:

• ['b', 'c', 1]
• ['anotherArray', 0, 'prop', 0]

Might take a bit more effort, thanks for raising the issue.

If possible having it bind to a map/dictionary and not a collection in the fractal store would be a workaround, although rather not have my library be that opinionated on how you structure your state.

note: possibly consider using immutable-setter or similar instead of our own as it handles arrays, and arrays at any point in the key path. Will investigate further.