From the portal docs:
Because portals use elements under the hood, you cannot query for elements inside of a portal when using Phoenix.LiveViewTest.element/3 and other LiveViewTest functions.
Instead, Phoenix.LiveViewTest.render/1 the portal element itself to an HTML string and do assertions on those:
<.portal id="my-portal" target="body">
<div id="something-inside">...</div>
</.portal>
# in your test, instead of
# assert has_element?(view, "#something-inside") <-- this won't work
html = view |> element("#my-portal") |> render()
assert html =~ "something-inside"
I’m assuming this means that LiveViewTest cannot interact with elements in portal’s? It would seem to be the case as my coworker ran into this and now I’m running into it. I have an extremely hacky work around to click buttons but I want to make sure I’m not missing something.
1 Like
That’s kinda unfortunate.
Portals are an ugly hack all around. In my JS framework my plan is to avoid implementing them at all if I can help it. I’m pretty sure everything I would use portals for is now covered by the top layer APIs (dialog/popover). In typical web platform fashion they’re essentially unusable for anything serious without JS escape hatches, but I can work with that.
This just reminded me to check how Anchor Positioning is doing, and apparently it’s set to drop in FF in 2 days! Then we will be free 
1 Like
I don’t disagree, though they sure are convenient! We use dialog/popover for modals, but portal is so convenient for context menus. I was using a “custom portal” implementation that was testable but quite hacky more to the point, a recent LiveView commit broke it. The portal implementation is far simpler but quite unfortunate about not being able to test with LiveViewTest. I do have the work-around, I just wish the docs were a lil’ bit clearer. I’ll likely just make a PR to try and clarify it.
1 Like
The dream is to use popover/anchor positioning for menus and tooltips. Soon!
