type1fool
@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.
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
chrismccord
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!
type1fool
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.
type1fool
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.
https://github.com/type1fool/yolo/tree/main/lib/yolo_web/live
There still seems to be value in preventing socket crashes when unexpected events and messages are received by a LiveView.
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?