Intercooler error handling patterns

[la...@satoriapp.com]

Intercooler error handling patterns

First of all, thanks a bunch to you, Carson for this marvellous tool. With my MVC prejudice, I was skeptical at first about the wisdom of managing client state this way; but it's turning out to be very practical once you make the necessary paradigm shift. The philosophy and design behind Intercooler is really smart; and there's so many use cases where it's a super elegant solution—saves tons of time, cost and complexity. Kudos!

That said, I'm not sure I'm understanding the Intercooler approach to AJAX error handling. It would be helpful to see some examples of this pattern.

I've been experimenting with some different approaches…

In my first attempt, I simply had the server returning HTML containing the appropriate error message if the request failed for some reason, to be inserted in the DOM in lieu of the requested data.

But this approach is flawed because it only works for a subset of errors wherein the server can still successfully process the request and produce a coherent response. It's not adequate in cases where the server throws an exception, or for network failures that prevent the server from being reached in the first place.

These cases require errors to be handled on the client. Is there a standard pattern for this in Intercooler?

The solution I've come up with is to pre-emptively add hidden error messages to placeholder divs for AJAX loaded content, and use ic-error-action to show these errors if the request fails.

```
<!-- elt to be replaced with result of ajax request -->
<div ic-get-from="..."
ic-replace-target="true"
ic-error-action="addClass:error">

<!-- show this while the request is inflight -->
<div class="loading_indicator"></div>

<!-- show this if the request fails -->
<div class="loading_error">
Content could not be loaded. Please try again.
</div>
</div>
<style>
.loading_error { display: none }
.error .loading_error { display: block }
.error .loading_indicator { display: none }
</style>
```

Is there a smarter way to handle this?

[Carson Gross]

Hi There,

Glad you are finding intercooler useful!  :)

Regarding error handling, in my experience there are two major classes of errors: inline form related errors and then global "out of band" errors.

For inline errors, the best thing to do is to flag the errors inline in the HTML you return (e.g. highlight an input field red with a descriptive error message).

For global errors, I typically use a custom event with a listener hooked up on the page body that invokes something like bootstrap notify:

http://bootstrap-notify.remabledesigns.com/

or jGrowl or whatever looks right in your app.

Then you can trigger the event using the IC-Trigger header, with the error message passed down as an argument to the event, so you'll have a header like this:

IC-Trigger:{"user-error", ["A bad thing happened.  Sorry."]}

and a handler like this:

$('body').on('user-error', function(event, msg) {

  $.notify({ message: msg },{ type: 'danger'});

});

This ensures that the error is seen by the user.  I also route all rails flash messages through this handler to unify the look and feel, but that's a rails specific idea.

Finally, I should mention the ic-post-errors to attribute, which will post all errors (including client side errors) to the specified URL:

 https://intercoolerjs.org/attributes/ic-post-errors-to.html

This is a nice feature that people should use, if only to collect error information about their site.  There are also attributes you can use to trigger scripts on various AJAX events, all of which begin with 'ic-on':

https://intercoolerjs.org/reference.html

Hope that helps.

Cheers

Carson

--
You received this message because you are subscribed to the Google Groups "intercooler-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intercooler-j...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.