In my total experience with LiveView, something that’s either a matter or personal ignorance or just problematic with how it works is generic error handling.
In the normal request/response cycle on a controller, catch-alls are pretty easy. We’ve got action_fallback to handle that and another controller out there dealing with errors.
I can’t see any way that this works nicely with LiveView in some sort of nice, transparent way. (Mind you, it’s quite possible someone provides an answer where I’m like, “D’oh!”)
To me, it’s looking like my main option would be to use on_mount for certain expected errors and then wrap other expected errors in helper functions that expect certain errors. That’s doable, but it seems like a repeat of assign_defaults in a different context.
There’s also one more issue:
While LiveView will try to recover by reseting state, most of the time the errors are not ephemeral. If the user does a thing that resulted in an error they’ll try again. We’re using Honeybadger for collecting these errors and I like presenting the user with, “Hey, provide this ID when contacting support.” A catch-all + flash or something seems like a workable solution here.
Is there something in the lifecycle I’m just missing and a sort of “blessed” way to do this? If not, what are some patterns that others have used for similar scenarios?
The essential problem with a catch-all in liveviews is the fact that in context of idiomatic state, your liveview will be in an invalid state once you hit the error. In contrast a controller fallback_action is not a state change, but a different pipeline for rendering the error response.
The easiest way I see this done is having some custom attributes for rendering the error flash, and in the catch-all statement, instead of letting the process crash, redirect to the same liveview with the passing of error as a parameter, this way you can ensure that the liveview will be in a clear state and you have the error on your hand.
Okay, so put another way… forget everything about fallback controllers and whatnot.
When a LiveView process crashes, is there any good way to get crash information (the exception) to the client? I suspect the new LiveView process has no idea about the prior one, but does the client itself? It seems like somewhere, something at least can know the two processes were associated.
If this were possible, it would actually solve most of the issues. You could have a helper function at essentially knows how to handle certain kinds of exceptions and display information in a flash, or a modal, or whatever. That doesn’t really matter. The trick is… can I get the exception data to the client?
I feel like all the pieces are definitely in place. Even if the JavaScript has to query something like, “Hey, this was my last process ID, did it leave an error?” That could be handled on_mount during remounting and then do whatever it needs to do to show whatever UI piece delivers that data to the user.
What we do is wrap mount/handle_* functions in undead which catches errors, logs them to Sentry, and shows the user an error page (if the error was on mount, to avoid loops) or a flash message with a description of the error and the option to submit feedback (which automatically includes a link to the Sentry error log) bonfire_ui_common/ui_common.ex at main · bonfire-networks/bonfire_ui_common · GitHub
Looking through the code, this is essentially what I want to do… only without having to constantly wrap things in something like undead/3. That seems like that is going to add a whole lot of noise all over the place and it’s still opt-in.
The developers have to do this all over the place, yes?
If forced, I would probably take some kind of middle ground where I have specialized LiveView functions for handling common scenarios like authorization and fetching resources where I expect errors and then handle them appropriately, but even then it ends up being a lot more ceremony than just having something generic that’s there to catch errors that it understands.
I’m sure it could be done transparently with macros but there’s something to be said for opt-in explicitness, but it’s not as much of a hassle as you expect, instead of wrapping all LiveView function bodies in undead, we do this:
and define do_handle_event/3 for view or component-specific logic, whilst LiveHandlers module takes care of error handling (and as a bonus also handles or delegates events that are used in more than one view or component).
There is, but I sometimes feel like “explicitness” becomes a bit of a cop-out. While Elixir and Phoenix are a really nice step back from the world of Ruby (which I still love, admittedly) in that sense, there are times when a pattern is so common that you just don’t want to have to pepper it all over the place.
One man’s explicitness is another man’s boilerplate! Haha.
Even the macro path isn’t great to me because I’d have to replace common conventions with a bunch of macros. That could actually work, but… I don’t love it. Actually, maybe I do love it. (I’m gonna be honest, when people are preaching to be careful about the use of meta programming, I kinda feel like someone is secretly looking at me.)
I probably need to dig into the LiveView lifecycle and see if I can cook something up. But I just had an idea about macros I have to look into. Thanks for the input either way. I dunno exactly where to take this, but this conversation has given me more options than I started with.
