sodapopcan
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.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
garrison
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
sodapopcan
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.
garrison
The dream is to use popover/anchor positioning for menus and tooltips. Soon!