type1fool
Defoverridable Function Fallbacks for LiveView Callbacks
@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.
Most Liked
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!
Last Post!
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
[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?
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #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 for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Enabling companies to succeed by building software people love.
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!"