@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.