adds reconcileWithKeys

[titoBouzout]

Summary

A suggestion to add reconcileWithKeys that @katywings and I have requested in the past. In some situations you want to use reconcile with objects that have keys differently named to id.

       const [target, setStore] = createStore({
        c: {
          a: [
            { ida: 1, name: "1" },
            { ida: 0, name: "0" }
          ],
          b: [
            { idb: 1, name: "1" },
            { idb: 0, name: "0" }
          ]
        }
      });

      const ref = target.c.a[1];

      const source = {
        c: {
          a: [{ ida: 0, name: "0 modified" }],
          b: [{ idb: 0, name: "0 modified" }]
        }
      };

      /*
      setStore("c", reconcile(source.c));
      expect(target.c.a[0]).not.toBe(ref);
      */

      setStore(
        "c",
        reconcileWithKeys(source.c, {
          keys: {
            a: { _key: "ida" },
            b: { _key: "idb" }
          }
        })
      );
      expect(target.c.a[0]).toBe(ref);

      expect(target).toEqual({
        c: {
          a: [{ ida: 0, name: "0 modified" }],
          b: [{ idb: 0, name: "0 modified" }]
        }
      });

How did you test this change?

Hehe, Im running into an issue when trying to write tests for it, when I run npm run test I get this error:

solid-js:test:  FAIL  store/test/modifiers.spec.ts > reconcileWithKeys
solid-js:test: TypeError: Cannot assign to read only property 'Symbol(solid-proxy)' of object '#<Object>'
solid-js:test: ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯

It works in the playground, so I'm lost at to whats going on, any ideas? 🙏🏼
https://playground.solidjs.com/anonymous/9167e413-e0b2-45bf-942a-3ca2153c0416

References

https://discord.com/channels/722131463138705510/780502110772658196/971305532034011156
https://discord.com/channels/722131463138705510/780502110772658196/1278247899616247808

[changeset-bot]

⚠️ No Changeset found

Latest commit: fc2d65a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[titoBouzout]

Ah, I see what's going on, it's failing a test (as expected), but then its throwing an unrelated error, that put me off, and I wasn't understanding. I think I can continue writing tests..

[ryansolid]

It's a cool Idea. There have been a few design variations on this. Not completely sure which makes the most sense. Mostly wonder if the changes to Stores in 2.0 will have bigger bearing on what the design ultimately is.

[ryansolid]

Thanks for the PR. This is a real use case, and it’s one that came up a few times around reconcile: different nested collections often use different identity fields, so a single default key like id is not always enough.

I’m going to close this as stale for Solid 2, though. Stores changed significantly in 2.0, and keyed reconciliation is now centered around the current reconcile(value, key) / projection-store APIs rather than adding a separate reconcileWithKeys helper.

I also don’t think this exact API is the shape I’d want to carry forward. The nested keys object with _key sentinels is powerful, but it adds a second reconciliation API and leaves some design questions around path semantics, swapped array behavior, and how this should compose with the newer projection store model.

If we revisit this, I’d rather do it as a fresh Solid 2 design. The current key function may already cover many cases, since users can choose identity from the item shape itself. For more ergonomic object-based key maps, I’d first want to explore whether they can compile to a normal custom key function outside the core reconciliation path, so the common reconcile implementation stays small.