@ryanwinchester Thanks for this article! I knew this was possible, and the examples made it clear how to implement handler fallbacks. This is super useful in the MyAppWeb.live_view/0 macro, where I don’t want to crash on unhandled events and messages.
Why Do This?
When a form control uses phx-debounce, often, an event will be triggered even after the user has submitted the form. For example, if a form has both phx-change & phx-submit events and an input uses phx-debounce="blur" or some large debounce timeout (200+), a user will often quickly type a value and hit Enter. When this happens, the submit event is triggered, the user may be redirected to another route, and the change event will be routed to a LiveView which wasn’t expecting it.
I applied the approach in the article to the MyAppWeb.live_view/0 macro, and now, those debounced events show up as logger warnings instead of crashing the socket. The user experience is much better this way, and now I can remove several copies of fallback event/message handlers that are no longer necessary.
Nice work!
Default LiveView Behavior?
Now, I wonder if this should be the default behavior in new LiveView applications. I vaguely remember @chrismccord mentioning real-world lessons learned after working at Fly, particularly how “let it crash” isn’t ideal for some (most?) user interfaces. The context was more around async tasks, but I think there’s a case to be made for gracefully handling unexpected events, messages, and providing some fallback implementations for the LiveView behaviour. Logging warnings seems like a good balance that will prevent Sentry and other error alerts when this common user behavior trips up our LiveView apps.
Latent debounces shouldn’t be happening if the form has been submitted as we specifically have code to handle this. Can you put together a minimal issues that reproduces the problem? Thanks!
1 Like
It could be that the primary app I’m maintaining is on an older version of PhoenixLiveView or we’ve somehow subverted that default behavior. I’ll spin up a fresh app with the latest versions and see if I can reproduce. If so, I’ll open an issue. 
On a fresh app with Phoenix 1.7.14 and PhoenixLiveView 1.0.0-rc.6, I can confirm debounced change event appears to be processed before the form submission event.
[debug] HANDLE EVENT "validate" in YoloWeb.DebounceLive
Parameters: %{"_target" => ["yolo", "name"], "yolo" => %{"name" => "as0d9f8as09df80a9sdf09as8df9asd08f"}}
[info] [validate: %{"name" => "as0d9f8as09df80a9sdf09as8df9asd08f"}]
[debug] Replied in 872µs
[debug] HANDLE EVENT "pewpew" in YoloWeb.DebounceLive
Parameters: %{"yolo" => %{"name" => "as0d9f8as09df80a9sdf09as8df9asd08f"}}
[info] [pewpew: %{"name" => "as0d9f8as09df80a9sdf09as8df9asd08f"}]
[debug] Replied in 454µs
[debug] MOUNT YoloWeb.PewpewLive
Parameters: %{"name" => "as0d9f8as09df80a9sdf09as8df9asd08f"}
Session: %{"_csrf_token" => "bEgWWu1cumbHhHVjCdmIbyn0"}
[debug] Replied in 121µs
There still seems to be value in preventing socket crashes when unexpected events and messages are received by a LiveView.
- During development, warning/error logs could raise awareness for developers about what’s happening in a way that might be clearer than the socket crash error.
- In production, users would be less alarmed when an omission or mistake has happened in the code, and developers could customize and opt into error logs.
I’m thinking of cases where a complex application uses PubSub, where a new message arrives in a topic and one or more subscribing LVs hasn’t been updated to handle it. Ideally, this would never happen, but mistakes and oversights do creep in sometimes.
The beauty of the fallback implementations is that the framework could still log errors by default without showing the big red flash to users. I understand it’s debatable whether crashes are good or bad UI and whether unexpected events & messages should be conveyed to the user at all. Outside of Phoenix, it seems that kind of thing would be logged to the browser console, and not always presented in the UI.
TLDR: Should it crash?
