Question: how to deal with data structures after decomposition into atomFamily?

[digizen]

Looking for guidance on the "correct" way to gather & iterate over data that's been decomposed into AtomFamily units.

Let's say I have an app that lets me draw shapes, and each shape's data is stored in an Atom, each atom being a part of an AtomFamily. I also have another Atom that has a list of the shape IDs so that I can iterate over the when doing the drawing. So far so good.

Now let's say I want to only display the blue rectangles. The color and shape is stored in the AtomFamily atoms, so the data is not immediately available.

The way my app works right now is that I have a data backing store (a JavaScript Map object) outside of the whole Recoil system. Every time I save a recoil atom I also push changes back into the backing store. Then, when I need to regenerate my "display list" I use that backing store.

My approach doesn't feel optimal, so I wanted to ask for your opinion of what a better approach should be. One possibility I came up with is to create a new list of shape IDs by "looking up" each atom, maybe inside a useRecoilCallback via the Snapshot property?

Is there a "correct" way of handling composite/complex data structures with recoil?

Thanks in advance for any guidance you can provide,
Greg

[42shadow42]

I think you have the right idea using useRecoilCallback and the snapshot, here is a sandbox that shows it working, not sure if it scales though.

https://codesandbox.io/s/dazzling-fermat-ui6zy

[digizen]

Thank you very much, very helpful!

[drarmstr]

If you're looking at synchronizing atoms with a backing store you may also want to consider the atom effects interface.

[drarmstr]

Atom effects would be useful for keeping each atom in sync, but not for creating new atoms.

[douglasg14b]

@drarmstr So effects would be a no-go if you want to track the values of an atomFamily, but also need to keep the atoms in sync with external sources?

What would be a viable route there that doesn't involve a significant amount of boilerplate?

[drarmstr]

atom effects are fine for tracking values of atom family members and keeping them in sync with an external source. But, they aren't good if you want that syncing to add new family members.

[douglasg14b]

Gotcha, maybe I should ask a new question as a discussion then. Since it's ambiguous or unclear how an external system is supposed to push changes to recoil, since the recommendation I keep reading is to use atom effects. And it's not like the recoil state is a global singleton I can just import 🤔

[42shadow42]

I think the discussion is a good idea. I have also wondered how to effectively work with server state.

[wsmd]

Another way of achieving this could be possible by using a selector as it allows you access the values of all other atoms and atom families. The selector in this case returns a list of ids that conform to the selected filters:

const shapeIdsState = atom({ key: 'shapeIds', default: [] });
const shapeState = atomFamily({ key: 'shape', default: null });
const shapeFilterState = atom({ key: 'shapeFilter', default: null })
const colorFilterState = atom({ key: 'colorFilter', default: null })

const filteredIdsSelector = selector({
  key: "filteredIdsSelector",
  get({ get }) {
    const ids = get(shapeIdsState);
    const shapeFilter = get(shapeFilterState);
    const colorFilter = get(colorFilterState);
    if (!shapeFilter && !colorFilter) {
      return ids;
    }
    return ids.filter((id) => {
      const shape = get(shapeState(id))
      // filtering logic goes here... (omitted for brevity)
    });
  }
});

function Shapes() {
  const filteredIds = useRecoilValue(filteredIdsSelector);
  return (
    <>
      {filteredIds.map(id => (
        <Shape id={id} key={id} />
      ))}
    </>
  )
}

[42shadow42]

There's a known issue with loops in selectors being slow and halting the program. I believe that selector would trigger that case.

[wsmd]

Interesting! Looks like you're referring to #914 & #900. That's good to know. I'll keep that in mind!

I haven't had any issues with this yet, but maybe because i haven't used it with a very large data set.

[drarmstr]

Note that that performance issue has now been optimized with Recoil 0.7

[drarmstr]

For ad-hoc usage to gather data from multiple atoms/selectors, there is also the waitForAll() util which can be used inline in a component directly to avoid making a new selector.

[thomaszdxsn]

For ad-hoc usage to gather data from multiple atoms/selectors, there is also the waitForAll() util which can be used inline in a component directly to avoid making a new selector.

for example I have a treeTable, every row is an atom. when a row collapsed the selector should recalculate, but multiple get() in one selector make it very very slowly