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?
