Would this be able to support Phoenix Live View as well? #2
Comments
|
For now we are focusing on JavaScript libraries like React, Vue, Alpine, ... I am not sure if this would be a good fit for this library itself. Maybe we can look into this in the future but not right away. |
|
@RobinMalfait Question, is Alpine still in the roadmap? |
RobinMalfait
added a commit
that referenced
this issue
Jul 4, 2024
As a general recap, when an outside click happens, we need to react to
it and typically use the `useOutsideClick` hook.
We also require the context of "allowed root containers", this means
that clicking on a 3rd party toast when a dialog is open, that we allow
this even though we are technically clicking outside of the dialog. This
is simply because we don't have control over these elements.
We also need a reference to know what the "main tree" container is,
because this is the container where your application lives and we _know_
that we are not allowed to click on anything in this container. The
complex part is getting a reference to this element.
```html
<html>
<head>
<title></title>
</head>
<body>
<div id="app"> <-- main root container -->
<div></div>
<div>
<Popover></Popover> <!-- Current component -->
</div>
<div></div>
</div>
<!-- Allowed container #1 -->
<3rd-party-toast-container></3rd-party-toast-container>
</body>
<!-- Allowed container #2 -->
<grammarly-extension></grammarly-extension>
</html>
```
Some examples:
- In case of a `Dialog`, the `Dialog` is rendered in a `Portal` which
means that a DOM ref to the `Dialog` or anything inside will not point
to the "main tree" node.
- In case of a `Popover` we can use the `PopoverButton` as an element
that lives in the main tree. However, if you work with nested
`Popover` components, and the outer `PopoverPanel` uses the `anchor`
or `portal` props, then the inner `PortalButton` will not be in the
main tree either because it will live in the portalled `PopoverPanel`
of the parent.
This is where the `MainTreeProvider` comes in handy. This component will
use the passed in `node` as the main tree node reference and pass this
via the context through the React tree. This means that a nested
`Popover` will still use a reference from the parent `Popover`.
In case of the `Dialog`, we wrap the `Dialog` itself with this provider
which means that the provider will be in the main tree and can be used
inside the portalled `Dialog`.
Another part of the `MainTreeProvider` is that if no node exists in the
parent (reading from context), and no node is provided via props, then
we will briefly render a hidden element, find the root node of the main
tree (aka, the parent element that is a direct child of the body, `body
> *`). Once we found it, we remove the hidden element again. This way we
don't keep unnecessary DOM nodes around.
RobinMalfait
added a commit
that referenced
this issue
Jul 4, 2024
As a general recap, when an outside click happens, we need to react to
it and typically use the `useOutsideClick` hook.
We also require the context of "allowed root containers", this means
that clicking on a 3rd party toast when a dialog is open, that we allow
this even though we are technically clicking outside of the dialog. This
is simply because we don't have control over these elements.
We also need a reference to know what the "main tree" container is,
because this is the container where your application lives and we _know_
that we are not allowed to click on anything in this container. The
complex part is getting a reference to this element.
```html
<html>
<head>
<title></title>
</head>
<body>
<div id="app"> <-- main root container -->
<div></div>
<div>
<Popover></Popover> <!-- Current component -->
</div>
<div></div>
</div>
<!-- Allowed container #1 -->
<3rd-party-toast-container></3rd-party-toast-container>
</body>
<!-- Allowed container #2 -->
<grammarly-extension></grammarly-extension>
</html>
```
Some examples:
- In case of a `Dialog`, the `Dialog` is rendered in a `Portal` which
means that a DOM ref to the `Dialog` or anything inside will not point
to the "main tree" node.
- In case of a `Popover` we can use the `PopoverButton` as an element
that lives in the main tree. However, if you work with nested
`Popover` components, and the outer `PopoverPanel` uses the `anchor`
or `portal` props, then the inner `PortalButton` will not be in the
main tree either because it will live in the portalled `PopoverPanel`
of the parent.
This is where the `MainTreeProvider` comes in handy. This component will
use the passed in `node` as the main tree node reference and pass this
via the context through the React tree. This means that a nested
`Popover` will still use a reference from the parent `Popover`.
In case of the `Dialog`, we wrap the `Dialog` itself with this provider
which means that the provider will be in the main tree and can be used
inside the portalled `Dialog`.
Another part of the `MainTreeProvider` is that if no node exists in the
parent (reading from context), and no node is provided via props, then
we will briefly render a hidden element, find the root node of the main
tree (aka, the parent element that is a direct child of the body, `body
> *`). Once we found it, we remove the hidden element again. This way we
don't keep unnecessary DOM nodes around.
RobinMalfait
added a commit
that referenced
this issue
Jul 4, 2024
As a general recap, when an outside click happens, we need to react to
it and typically use the `useOutsideClick` hook.
We also require the context of "allowed root containers", this means
that clicking on a 3rd party toast when a dialog is open, that we allow
this even though we are technically clicking outside of the dialog. This
is simply because we don't have control over these elements.
We also need a reference to know what the "main tree" container is,
because this is the container where your application lives and we _know_
that we are not allowed to click on anything in this container. The
complex part is getting a reference to this element.
```html
<html>
<head>
<title></title>
</head>
<body>
<div id="app"> <-- main root container -->
<div></div>
<div>
<Popover></Popover> <!-- Current component -->
</div>
<div></div>
</div>
<!-- Allowed container #1 -->
<3rd-party-toast-container></3rd-party-toast-container>
</body>
<!-- Allowed container #2 -->
<grammarly-extension></grammarly-extension>
</html>
```
Some examples:
- In case of a `Dialog`, the `Dialog` is rendered in a `Portal` which
means that a DOM ref to the `Dialog` or anything inside will not point
to the "main tree" node.
- In case of a `Popover` we can use the `PopoverButton` as an element
that lives in the main tree. However, if you work with nested
`Popover` components, and the outer `PopoverPanel` uses the `anchor`
or `portal` props, then the inner `PortalButton` will not be in the
main tree either because it will live in the portalled `PopoverPanel`
of the parent.
This is where the `MainTreeProvider` comes in handy. This component will
use the passed in `node` as the main tree node reference and pass this
via the context through the React tree. This means that a nested
`Popover` will still use a reference from the parent `Popover`.
In case of the `Dialog`, we wrap the `Dialog` itself with this provider
which means that the provider will be in the main tree and can be used
inside the portalled `Dialog`.
Another part of the `MainTreeProvider` is that if no node exists in the
parent (reading from context), and no node is provided via props, then
we will briefly render a hidden element, find the root node of the main
tree (aka, the parent element that is a direct child of the body, `body
> *`). Once we found it, we remove the hidden element again. This way we
don't keep unnecessary DOM nodes around.
RobinMalfait
added a commit
that referenced
this issue
Jul 5, 2024
* use `span` as default element for `Hidden` component This improves the HTML DOM tree if this happens to be used in let's say a `p` tag where `div` elements are not allowed. The `Hidden` element is hidden so it doesn't really matter what the underlying element is. Fixes: #3319 * refactor `useRootContainers` and introduce `MainTreeProvider` As a general recap, when an outside click happens, we need to react to it and typically use the `useOutsideClick` hook. We also require the context of "allowed root containers", this means that clicking on a 3rd party toast when a dialog is open, that we allow this even though we are technically clicking outside of the dialog. This is simply because we don't have control over these elements. We also need a reference to know what the "main tree" container is, because this is the container where your application lives and we _know_ that we are not allowed to click on anything in this container. The complex part is getting a reference to this element. ```html <html> <head> <title></title> </head> <body> <div id="app"> <-- main root container --> <div></div> <div> <Popover></Popover> <!-- Current component --> </div> <div></div> </div> <!-- Allowed container #1 --> <3rd-party-toast-container></3rd-party-toast-container> </body> <!-- Allowed container #2 --> <grammarly-extension></grammarly-extension> </html> ``` Some examples: - In case of a `Dialog`, the `Dialog` is rendered in a `Portal` which means that a DOM ref to the `Dialog` or anything inside will not point to the "main tree" node. - In case of a `Popover` we can use the `PopoverButton` as an element that lives in the main tree. However, if you work with nested `Popover` components, and the outer `PopoverPanel` uses the `anchor` or `portal` props, then the inner `PortalButton` will not be in the main tree either because it will live in the portalled `PopoverPanel` of the parent. This is where the `MainTreeProvider` comes in handy. This component will use the passed in `node` as the main tree node reference and pass this via the context through the React tree. This means that a nested `Popover` will still use a reference from the parent `Popover`. In case of the `Dialog`, we wrap the `Dialog` itself with this provider which means that the provider will be in the main tree and can be used inside the portalled `Dialog`. Another part of the `MainTreeProvider` is that if no node exists in the parent (reading from context), and no node is provided via props, then we will briefly render a hidden element, find the root node of the main tree (aka, the parent element that is a direct child of the body, `body > *`). Once we found it, we remove the hidden element again. This way we don't keep unnecessary DOM nodes around. * update changelog * Update packages/@headlessui-react/src/hooks/use-root-containers.tsx Co-authored-by: Jordan Pittman <[email protected]> * Update packages/@headlessui-react/src/hooks/use-root-containers.tsx Co-authored-by: Jordan Pittman <[email protected]> * Update packages/@headlessui-react/src/hooks/use-root-containers.tsx Co-authored-by: Jordan Pittman <[email protected]> * Update packages/@headlessui-react/src/hooks/use-root-containers.tsx Co-authored-by: Jordan Pittman <[email protected]> * Update packages/@headlessui-react/src/hooks/use-root-containers.tsx Co-authored-by: Jordan Pittman <[email protected]> * use early return --------- Co-authored-by: Jordan Pittman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think I see what you're doing here.
If so, I wouldn't mind making some PRs in the future for Phoenix Live View versions.
I'm not sure if it would be possible to easily distribute this sort of thing as a hex package though (maybe), and maybe just example files for copypasta if that is the case.
The text was updated successfully, but these errors were encountered: