[API] onResponse was not obeying return dataType

[bockscar]

I'm new to Semantic and trying to get brain around a few concepts. Thank you for this awesome work.

I am exploring using Semantic with a legacy backend. The legacy backend returns JSON that requires processing. One key in the returned JSON is 'html' from which, say a tab's HTML contents, would be pulled.

Though my question applies to all API calls, running with tabs is a useful case study. A tab is hardwired to seek and get returned from server plain HTML. My objective would be to leverage as much Semantic tab logic as possible but get it to work with this legacy JSON backend.

This discussion regarding a related topic discusses the use of 'mockResponseAsync' for a related purpose:
#1736

It seems onResponse is the simpler solution. I was glad to find it. But I did not understand why the response text was being transformed into a hash before being sent to the 'onResponse' callback. The first thing I need to do on the other end is reassemble the original response text so I can process it in proprietary fashion. Maybe there's a reason for this transformation?

My suggestion retains the default and offers a flag to skip this wasteful transformation so it needn't happen every server hit if it is not necessary.

Maybe I misunderstood 'mockResponseAsync' and that's where I should be working? If not, maybe the default behavior for 'onResponse' transforming the text might be confusing to others as well.

Thanks for the awesome work. I look forward to getting deeper. Even without this change, it's cool that hooks are in place so I can wire Semantic into a legacy app.

[jlukic]

If you could create a text case that reproduces the specific issue with onResponseAsync it'd be easier to talk about.

Most modules that consume API results allow for field mappings in JSON using the fields settings object.
http://semantic-ui.com/modules/search.html#using-different-response-fields

[bockscar]

Sorry. Wanted to include some info on the use case if it happened to apply to anyone else. The callbacks actually do exactly what we need (aside from this minor friction).

Heart of the question was understanding why response is passed after being converted to an object. Other places response is passed as a string. That's why this usage stood out and confused me initially...because I was expecting a string:
settings.onResponse.call(context, $.extend(true, {}, response))

[jlukic]

It looks like this might be a bug when dataType is not specified to the default JSON. I'll have to take a look.

I don't think we need a separate setting, it should just mimic the expected response type.

[jlukic]

I've taken a different angle, but this should fix it as long as you are specifying a different dataType than JSON or JSONP