Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing response based on responseType #175

Open
olishmollie opened this issue May 21, 2017 · 4 comments
Open

Parsing response based on responseType #175

olishmollie opened this issue May 21, 2017 · 4 comments

Comments

@olishmollie
Copy link

olishmollie commented May 21, 2017

I'll start by saying thanks for an awesome bit of software. I've been having a lot of fun using jasmine and jasmine-ajax.

I'm testing a polling engine that wraps XMLHttpRequest, and want to test that the responseType specified will return the correct type (i.e. if I specify type 'json', xhr.response should be an object). Here's what I'm trying to do:

    describe('response types', function() {

      it('parses a response based on its type', function() {
        var dataHandler = jasmine.createSpy('success');
        pollr.on('data', dataHandler);
        pollr.responseType = 'json';
        pollr.start();

        jasmine.Ajax.requests.mostRecent().respondWith({
          'status': 200,
          'response': '{message: "ok"}'
        });

        expect(dataHandler).toHaveBeenCalledWith({ message: 'ok'});
      });
    });

I know this is flawed because after logging a few real xhrs it seems like my browser parses the json before xhr.response is available, and a realistic response would have an object in the response field. But since a real xhr parses a response based on responseType, I (probably naively) think that jasmine-ajax should somehow do the same. Thanks again.

@olishmollie olishmollie changed the title xhr.responseType Parsing response based on responseType May 21, 2017
@olishmollie
Copy link
Author

olishmollie commented May 21, 2017

Whelp, I got the tests to pass. I made it 'responseText': '{"message": "ok"}', and I had to set 'responseType': 'json' in the response. But since I'm setting the xhr responseType in my code, shouldn't I be able to forgo specifying it in the response?

@slackersoft
Copy link
Member

I don't know what your pollr object does with the responseType setting. Jasmine-Ajax just looks at the response object you pass in when setting up the full response, since that is more how the server would behave anyways.

Hope this helps. Thanks for using Jasmine! Closing.

@garygreen
Copy link

@slackersoft I've also just come across this. The behaviour of jasmine does seem a bit strange.. if you set a responseType on your xhr the instance, the response should have the same responseType set. That's how xhr works in the browser. See below example:

In browser

var req = new XMLHttpRequest;
req.responseType = 'json';
req.addEventListener('load', function(response) {
  // This will come back with JSON response type.
  console.log('Response type is: ' + response.currentTarget.responseType);
});
req.open('GET', 'https://api.github.com');
req.send();

With jasmine:

var req = new XMLHttpRequest;
req.responseType = 'json';
req.addEventListener('load', function(response) {
  // This will come back with EMPTY response type.
  console.log('Response type is: ' + response.currentTarget.responseType);
});
req.open('GET', 'https://api.github.com');
req.send();

var request = jasmine.Ajax.requests.mostRecent();

request.respondWith({
	status: 200,
	responseText: JSON.stringify({ name: 'test' })
});

@slackersoft
Copy link
Member

It looks like the original implementation of responseType missed the intended implementation from the spec. Currently Jasmine-Ajax expects the response object to have a responseType set in order to configure response correctly, but in a deeper dive into the spec now, it looks like this property is really intended to be set by the requester in the manner you mention here.

I would be happy to review a pull request to correctly respect the responseType set before the request is made. For now, we should leave the current functionality (probably letting the the response win if set), but I would like to see a deprecation message printed somewhere, (possibly with Jasmine's new deprecation helper on versions where it exists).

Reopening. Thanks for the additional info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants