-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better Pages.Driver.Conn support #9
base: main
Are you sure you want to change the base?
Conversation
…acilitate cleaner param sending for static forms
I think it would be nice to keep the current API |
Hey Andrew, thanks for this PR! I'm still reading through it and thinking about it :) |
… if there are multiple elements with matching selector
@AndroidOatmeal @cbortz I just pushed some changes to main that allow you to use I've also pushed a bunch of fixes to initializing pages and to navigating between live and dead views. Best of all, I've been adding tests to cover the latter, so if you run into any more weirdness we can try to capture them in new test cases. I did have to make a breaking change to the Driver behaviour, but I was able to do the rest without breaking changes to the main |
Hello friends, here is my much awaited PR to make static pages work more-or-less seamlessly with Pages. See below for a summary of changes.
Change summary
Pages.visit
now decides which driver to useDuring my testing on our code base, there was some wonkiness switching between live view and conn page drivers. Sometimes I would interact with a page and end up with a live view driver when I should have had a conn driver, and vis versa. For example, see this old case in
Pages.Driver.LiveView.new/2
lib/pages/driver/live_view.ex:33. If it were passed in a:redirect
tuple, that meant we should switch to a conn driver, but the existing implementation simply passed the static redirect route back tonew_live/2
and ultimately failed to figure out where it was going. These cases were difficult to enumerate and hard to track down.Instead, I took some advice from the
PhoenixTest
implementation and letPages.visit/2
figure out which driver to use in a very simple manner. Simply try toget
a given path, figure out if we're a live view, a conn, or a redirected conn, and build the appropriate driver. This meant that the driver's respectivenew/2
functions could be much simpler, sincevisit/2
was the one assembling the driver structs. I opted to get rid ofnew/2
all together and added some simplebuild/*
functions on the respective drivers that return a necessary struct.submit_form/*
andupdate_form/*
arity changesThe original impetus for me adding the conn driver functionality was a simple controller that accepted a single parameter:
Note that this static form had no changes or schema. The corresponding controller action clause looks like this:
The existing pages API simply wouldn't play nice with this form param structure because a
schema
atom is required. And unfortunately I couldn't make that argument optional because there are existing default arguments (hidden_attrs
) and the compiler wouldn't allow that — it couldn't always figure out which case was correct and which parameter belonged in which slot.My solution was to provide two flavors of
submit_form
:If you want to use the legacy
:schema
API you can, but you need to explicitly provide hidden attrs. In order to prevent duplication between the live and conn drivers, I put the:schema
merging logic at the top levelPages.submit_form/5
call. This means that the driver implementations now only need to implement a single function:submit_form(page, selector, params, hidden_attrs)
. Something very similar was done forupdate_form/*
as well.Pages.HtmlForm
This was lifted from
PhoenixTest
and modified to useHq
. I also borrowed logic for the conn driver from this library; specifically adding anactive_form
field to the struct that could hold onto the state of the form in memory.The future — unit testing
Pages
The PhoenixTest library has actual unit tests for its functionality, something we're sorely missing right now. I haven't looked into the specifics, but the author seems to create real live view and static routes for the purpose of testing various scenarios. [https://github.com/germsvel/phoenix_test/blob/main/test/phoenix_test/live_test.exs](See https://github.com/germsvel/phoenix_test/blob/main/test/phoenix_test/live_test.exs)
Our entire AT suite is green using this PR, but it's certainly possible I broke something along the way when writing this.
That's it. Lemme know your thoughts!