Description

Many UI libraries provide fade in/out effects for their menus. Currently, onClose runs after the resolution is cleared and the menu is removed from the DOM, before anything can be cleaned up by the library user.

The desire is to allow onClose to run async, as follows:

  const closeTypeahead = useCallback(async () => {
    try {
      if (onClose != null && resolution !== null) {
          await onClose();
      }
    } finally {
      setResolution(null);
    }
  }, [onClose, resolution]);

The idea is that, if a consumer wanted to manage the entire process, they would still have their component rendered, to do what they want, before returning control to Lexical:

const [opened, setOpened] = useState(false);

const onClose = async () => {
  setOpened(false);
  await waitForMenuToClose();
}

<LexicalTypeaheadMenuPlugin
  ...
  onClose={onClose}
  menuRenderFn={
    (anchorElementRef, ...) => createPortal(
      <Menu opened={opened} setOpened={setOpened} ... />,
      anchorElementRef.current
    )
  }
/>

When opening the menu, it's easy enough to use the existing menuRenderFn function to start the transition and do what we want with the fade in. It's the fade out that's problematic.

Impact

Making this async potentially changes the execution order of the menu closure and state updates surrounding that. Potentially the consumer could manipulate the editor state in this period and cause some confusion if it's told to reopen in this period? If they're already doing that today, it already seems like said consumer is asking for trouble.

Beyond that, this shouldn't impact existing users.