Allow response modifications in onAfterSuccess callback

[prantlf]

I would like to call the server, but modify the response to include additional data, before it is consumed by the caller. It helps the development, when the server API is only partially ready or when you want to test an alternative scenario, which would be not so easy to prepare on the server. I tried the proxy option:

mockjax({
  url: '/api/currentuser',
  proxy: '/api/currentuser',
  onAfterSuccess: function (response) {
    response.image = '/images/profile
  }
});

This way "almost" works, except for:

1. The onAfter[X] callbacks have no arguments. Was there any reason not to propagate the jQuery callback arguments 1:1 there?
2. MVC Frameworks like Backbone.js register on success and error callbacks to update their model with the server response. If the server response needs to be modified before it reaches the model controller, the onAfter[X] have to be executed before the jQuery originals.

I demonstrate this change in the propagate-callback-arguments branch.

Thinking further, the proxy option would work only for simple scenarios, allowing only url, type and data passed to the proxy. Other options like headers or contentType may be missing. I realized, that passing the request through to the server and updating the response may need more than the proxy offers. I introduced a new passThrough option, which makes the mocking simpler:

mockjax({
  url: '/api/currentuser',
  passThrough: true,
  onAfterSuccess: function (response) {
    response.image = '/images/profile
  }
});

I demonstrate this change in the passthrough-requests branch.

I got the "half-mocking" scenario, when the server responds, but the respond needs to be "massaged" a little before passed to the caller, working using the two changes above. Would you accept them into the official mockjax? Thanks!

[jakerella]

Definitely an interesting feature that we hadn't considered before. I'll try to take a closer look at your branch, but right off the bat I can tell you that we would need to integrate this into the v2 branch, which did reorganize some code, so you might want to start from there.

[prantlf]

Thanks for considering it! I will certainly create a PR against the v2 branch.

It is an important feature for us. Existing REST API resources are often extended. As long as the extension is not finished, developing a client needs a mock. But mocking the entire request would be inefficient; we'd like to mock minimally - just the missing features.

[hansgru]

+1

[prantlf]

I created #232 for the first point against the v2 branch. Another PR - #233 - for the second point. They aim to resolve this issue.