$.getJSON(url [, data] [, success])
And I wanted to provide an error handler. So, our corporate library (represented by
LIB
) has a function like:LIB.getJSON(url, data, success [, error])
I also didn’t know if I could rely on getting a response body from error events, so where possible, errors are returned as 200 OK
{Error:true,ErrorMsg:"boom"}
and the LIB.getJSON
catches these and invokes the error callback instead of the success one.(One more sub-optimal design choice: like, almost the whole point of
LIB.getJSON
is to pass an error handler and let the user know “okay. we are not loading anymore.” But notice that the error handler is still considered optional for some reason.)If I were designing this from scratch today, the service would return errors as HTTP error responses, and I’d use the “new” (added in 1.5, after I started jQuery’ing) Deferred methods.
function success (data, txt, xhr) {
// ...
}
function error (xhr, txt, err) {
var r;
try {
r = $.parseJSON(xhr.responseText);
} catch (e) {}
// ...
}
$.getJSON(url, data)
.then(success, error);
Result: a more RESTful design, with less glue.
I’d probably still have an “error adapter generator” function which converts all the possibilities for xhr/txt/err down to a single message string, and pass
newErrorHandler(showErrorUI)
as the error callback into .then()
. But the point is, there’s no need to have LIB.getJSON
as a whole anymore, to both accept an error callback and filter ‘successfully returned error’ values.
No comments:
Post a Comment