-
Examples would be Set & Map structures. Obviously when this has shown up for other reference based structures (arrays & objects) the obvious answer is to make it immutable by rebuilding a whole new array since both these items are very simple to make immutable. However, when using a Set or Map this isn't really as viable. Of course with a Map you could always fall back to a simple object, but in the scope of a Set, it has unique functionality that's needed. In theory when we call a setter with
ImmutableJS does seem to have an immutable version of a Set, but based on the nature of how our set is used as read-only it'd be preferable to simply have some pattern for re-running the getter like with the refresh pattern. This would also speak to when you have large chunks of data with objects you'd rather mutate in a structure way i.e. using Maps. I can't really see any large discussion about this point, but it seems like an important one. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Mutable data structure doesn't follow the React contract, and it may behave weirdly with Concurrent React. That being said, what we can do with atoms is to create a version. The idea is similar to atomWithRefresh. const internalSetAtom = atomWithLazy({
set: new Set(),
version: 0,
});
const mySetAtom = atom(
(get) => get(internalSetAtom).set,
(get, set, action: SetAction) => {
const current = get(internalSetAtom)
if (action.type === 'add') {
current.set.add(action.value)
set({ ...current, version: current.version + 1 })
} else if (action.type === 'remove') {
current.set.delete(action.value)
set({ ...current, version: current.version + 1 })
}
},
); Actually, in this example, we don't need |
Beta Was this translation helpful? Give feedback.
Mutable data structure doesn't follow the React contract, and it may behave weirdly with Concurrent React.
That being said, what we can do with atoms is to create a version. The idea is similar to atomWithRefresh.