-
Notifications
You must be signed in to change notification settings - Fork 927
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
phx-disable-with should handle the case of navigating after a submit better #3412
Comments
Also I can provide a replication but you can replicate this yourself by making any LV using |
There is also what I think is a bug with the phx:page-loading-stop event in this workflow. When the phx-disable-with text comes back, you will also see the loading bar (Assuming you're using it) go away. It will not come back even though a page navigation is in fact in progress. |
I ran into this as well in forms that use ‘trigger-action‘. The loading text immediately goes away or sometimes doesn't even have time to show up before the liveview responds, and the form sits there as if nothing happened for a while if the controller takes a long time to process the request. I wish we could hint to the liveview "hey keep the button disabled as we're going elsewhere now". |
@srcrip note that the behavior you've described in https://elixirforum.com/t/how-does-liveview-know-when-to-remove-phx-disable-with-from-form-submits/61370/3 doesn't happen any more in the latest rc. I assume it's related to the locking changes in rc-3. I'll need to look into the trigger-action case. |
Gotcha. I am will update my app to the latest RC and report back if I'm still seeing this. |
Hey yall,
check out this as context: https://elixirforum.com/t/how-does-liveview-know-when-to-remove-phx-disable-with-from-form-submits/61370
The thrust of the complaint here is that phx-disable-with gets removed from the element after the submit is done, but before navigation happens. So there is a flash of the old text that comes back while the navigation happens.
I think it would be preferable for the JS that powers phx-disable-with to keep the disabled text on the element if a navigation happens immediately after submission completes. I don't think that would be too magical, but perhaps we can think of alternatives if that's a concern.
The text was updated successfully, but these errors were encountered: