LiveViewTest: expose full page HTML after live view updates in a public API

Phoenix Forum Proposals/Suggestions
, ,
1

Intro

Currently when mounting a LiveView with Phoenix.LiveViewTest.live/2 you can get the full page HTML as a string, but then, after doing some updates (triggering events etc.), it’s no longer possible to get the up-to-date full page HTML. It’s only possible to get the HTML of the LiveView with Phoenix.LiveViewTest.render/1, without any layouts.

What am I asking for?

It would be great if there was a function like render_page(live) or page_html(live) in Phoenix.LiveViewTest that would allow you to get the up-to-date full page HTML at any time of the LiveView’s lifecycle.

Is my suggestion easily implemented?

This is a post that triggered my request: In a LiveView test, how can I get the full page HTML after the initial render?

As mentioned in that post, there is technically an unofficial way to get the full page HTML by using the private genserver Phoenix.LiveViewTest.ClientProxy which is able to produce a full page HTML after LiveView updates because it’s needed for Phoenix.LiveViewTest.open_browser/2. I believe that makes it reasonably easy to implement what I’m asking for.

Would my suggestion benefit Phoenix of the community as a whole?

It would make it possible to, in tests, send the HTML of the LiveView in the current state to an HTML validator which helps to catch some types bugs (duplicate ids, invalid tag nesting, labels not assigned to any inputs etc.). HTML validators work on full documents, not fragments, hence the need for the full page HTML.

I won’t lie, I think the number of people who would actually do this is very low. My request might be a bit selfish - I have written a library that makes it easy to validate HTML in tests that I’ve been using for years, and this change would make my library more useful for LiveView tests. But I would like to encourage more people to do HTML validation because it helps produce higher quality web apps and catch some accessibility issues.

There might be completely different use cases for this that are not crossing my mind currently.

Any downsides to adding this? Definitely having one more public function to maintain is a downside.

Please also consider volunteering to work on any implementations yourself

I would love to work on this. I would just need approval on the chosen function name, I don’t feel very confident about my proposed names.

1 Like
2

I think this is a great idea and I would be interested in using something like this. Since this is essentially linting, it would be ideal if it could be a heex extension (being that it is already html-aware) and not have to use tests. I’m not sure that heex is extensible, though.

Is your current library available anywhere?

Also, does the Phoenix.LiveViewTest.ClientProxy output produce the exact same output as open_browser? I ask because I’ve notice that there are some discrepancies in how open_browser renders root.html.heex content vs what is actually rendered in the running app.

EDIT: I think any of render_page, render_html, or even render_dom are all fine options.

1 Like
3

Yes, my library is this: vnu-elixir

The only discrepancy I noticed between the real running app and the HTML returned by Phoenix.LiveViewTest.ClientProxy is that the latter is missing a DOCTYPE because Floki removes that. Maybe there are more discrepancies but I haven’t been testing LiveViews long enough to notice.