I would like to add that Proxy is not supported in older browsers like IE11. Also, why do we need to use Proxies here when we are already 'proxying' the backing set while returning add, remove, and other modifiers from the hook? We may add logic to these functions to force rerender when called. An ideal implementation would be to check if the set actually changed and needs rerender (yet this functionality should be configurable using a boolean flag like 'pure' to prevent adding a runtime penalty when it is not needed)

I like the idea of providing the exact same APIs as Set and Map and storing the state aside from useState and triggering updates manually.

But I'm skeptical about introducing Proxy here, due to performance penalty and unavailability in older browsers.

Great points @laleksiunas @streamich! You could definitely have a pseudo "proxy" instead of Proxy and also only force render on mutations (i.e. based on the response from set.add() or map.set()). I'll try to update my demo soon and get a PR open.

@mattboldt I was thinking about a builder function that can create this kind of hooks, like the one below (just straight out of my mind, not tested):

const createDataEntityHook = (createDefaultValue, createModifiers) => () => {
  const forceUpdate = useForceUpdate();

  const backingEntity = useMemo(createDefaultValue, []);
  const modifiers = useMemo(() => createModifiers(backingEntity, forceUpdate), []);

  return [backingEntity, modifiers];
};

And to use it:

export const useSet = createDataEntityHook(
  () => new Set(),
  (set, update) => ({
    add: value => {
      const setSizeBefore = set.size;

      set.add(value);

      // check if set changed to prevent unnecessary rerenders (might be turned off by configuration)
      if (setSizeBefore !== set.size) {
        update();
      }
    }
    // other functions
  })
);

What do you think?