Me, today: “Why am I getting two different objects back from an
This is a tale of unexpected promises. There were two functions calling two
methods on the backend service using an
$http.post call. The client-side
handlers were written by two different developers. Because the handlers should
have been working with the same kind of object, I saw an opportunity for some
code reuse. But somehow, the handlers were getting different objects.
Both backend service methods return the same kind of object, something like this:
Handler A received an object just like the one described above. But Handler B got the expected object wrapped inside another object, like this:
Both handlers were chained to
$http.post calls. Why were they getting
It turns out that
$http.post can return promises with different interfaces,
depending on how you attach your handlers to the promise.
$http.post method returns a Q-style
promise. (It’s instructive to look at the
Angular q.js source code.)
That promise only has the properties
$http service decorates that promise with two additional properties:
error. These two extra properties unpack the full response
object into its components, and take a function like:
Handler A was relying on these extra
error methods, and got the
expected object in the first parameter.
Handler B attached a
then to the
$http() call, and got the full
response object instead. The expected object comes attached to the response
data property. Worse, the promise returned from
does not have
error properties. So anyone trying to add
error handler to the chain will discover they don’t work.
I rewrote Handler B to use
success instead of
then et voila: Handler B
started getting the expected object, I could reuse handler code, and
everything was copasetic.