Update Elixir: Why your LiveViews shall be minimal and fast

Author: mbuffa

content/articles/20251124-elixir-live-view-mount-blocking-ops.md

@@ -20,7 +20,7 @@ But it would actually have a couple of effects.
 
 After a successful deployment, with a substantial amount of users connected, their LiveViews would try to reconnect to the newly deployed backends, may take a while to reconnect, freeze the UI meanwhile, or even end up in a timeout state. Also, navigations between pages would be much slower and probably noticeable.
 
-Also, in development, you would eventually trigger the code reloader, that would in turn kill and reset your current LiveView(s). potentially depleting your Ecto pool, and get a frozen UI that would eventually timeout, with a mysterious error in the JS logs (`Unable to join (timeout)`). It doesn't take more than a few tabs open or several active LiveViews to trigger this situation with the default setup of 10 connections.
+Also, in development, you would eventually trigger the code reloader, that would in turn kill and reset your current LiveView(s). potentially depleting your Ecto pool. It doesn't take more than a few tabs open or several active LiveViews to trigger this situation with the default setup of 10 connections.
 
 Bottom line is: that particular callback should always be minimal, and you should always try to do things asynchronously as much as psosible. `start_async/3` and `assign_async/3` are excellent ways to help you do that. And to be fair, this is not a nice to have. It should be mandatory for all production apps and as such, treated as a high priority flaw to address.