{"version":3,"file":"portal-host.cjs","names":[],"sources":["../../../src/components/Portal/portal-host.ts"],"sourcesContent":["import { useState } from \"react\";\nimport { useFullscreenElement } from \"@/hooks/use-fullscreen-element\";\n\n/**\n * The element a portal should render into.\n *\n * `document.body` is the obvious answer and the wrong one while the page is in\n * fullscreen: the browser paints only the subtree of the fullscreen element, and\n * `body` is outside it. An overlay portalled there exists in the DOM, has a\n * measured box, and is neither visible nor clickable — `elementFromPoint` at its\n * centre returns whatever sits behind it. Nothing throws and nothing logs, so the\n * app is left holding a dialog nobody can see.\n *\n * The fullscreen element can appear and disappear while a portal is mounted, so\n * the host is state rather than a one-time read. That subscription — the two\n * events, standard and WebKit-prefixed — lives in `useFullscreenElement`, because\n * `useFullscreen` needs the identical fact to answer a different question; this\n * module only asks it where to mount.\n */\n\n/**\n * Resolve where a portal should mount, following fullscreen changes.\n *\n * The first value is resolved during render rather than in an effect, so an\n * overlay that opens still mounts in the same commit it used to — the\n * subscription only follows changes from there.\n *\n * @returns The fullscreen element while one is presented, otherwise\n * `document.body`; `null` in any environment without a `document`.\n */\nexport function usePortalHost(): Element | null {\n    const fullscreen = useFullscreenElement();\n    const [body] = useState<HTMLElement | null>(() =>\n        typeof document === \"undefined\" ? null : document.body,\n    );\n\n    return fullscreen ?? body;\n}\n"],"mappings":"iFA8BA,SAAgB,GAAgC,CAC5C,IAAM,EAAa,EAAA,qBAAqB,EAClC,CAAC,IAAA,EAAQ,EAAA,SAAA,KACX,OAAO,SAAa,IAAc,KAAO,SAAS,IACtD,EAEA,OAAO,GAAc,CACzB"}