res.body return a ReadableByteStream object on Chrome

[tarikjn]

Hi,

I am using the latest verison of Chrome on OS X (Version 50.0.2661.102 (64-bit)), with Frisbee, and response.body will return ReadableByteStream instead of an expected response object as built by the result of parsing a json response.

This seems to be the standard, but then why would the frisbee doc give this example? Trying to read the response with response.json() will return the following error: Uncaught (in promise) TypeError: Already read.

[niftylettuce]

@tarikjn if you submit a pull request I can take a look at reviewing and merging it. Right now we're really geared towards writing our own custom glue around the standard fetch API, otherwise might as well use the fetch API directly

[tarikjn]

@niftylettuce I am confused, this is a bug report to say that Frisbee does not work on Chrome, not to suggest changes to the Frisbee API.

Also the Frisbee API does not document how one is expected to use the response, so I have no idea if the response should be expected to be identical to a fetch response.

[niftylettuce]

@tarikjn Ah! Okay, I can get tests for all the browsers in and figure out what the bug is there.

The usage for the API is documented in the example.

For instance, if you want to make a POST request and pass along in the body the param name=tarikjn:

import Frisbee from 'frisbee';

const api = new Frisbee({
  // ... options
});

makeRequest();

async function makeRequest() {
  const res = await api.post('/', { body: { name: 'tarikjn' } });

  // if the response was not 200 OK status code
  // then an error will happen and we'll attempt to
  // parse the body for the error response message,
  // we'll look for `{ error: { message: 'some error msg' } }`
  // and also just `{ message: 'some error message' }`
  //  in the response body
  if (res.err) throw res.err;

  console.log('response body', res.body);

  console.log('response headers', res.headers);

}

[tarikjn]

Alright, so it looks like the problem is that .body conflicts with fetch browser implementations that support steams as they also use .body for the stream.

[niftylettuce]

@tarikjn did you ever find a workaround or patch for this? I'd love to have a collaborator on Frisbee!

[tarikjn]

I actually discussed this issue with @stayman last week. We came to the conclusion that the native fetch object should really be nested in the Frisbee response instead of merged, this would avoid this issue and potentially others, while avoiding confusion on native vs. lib API.

@stayman suggested using Karma for browser testing.

Unfortunately, none of us have time to contribute yet, and likely won't until next year, although we'd love to. Hopefully these suggestions in the meantime are helpful.

[OmgImAlexis]

@tarikjn if you can add a failing test I'll have a look at this when I'm free.

[fourcolors]

I'm getting this error using react native in a saga right now. Specifically the part about Invalid JSON

[niftylettuce]

Just an update here - you can look at original response via res.originalResponse

As of v2.0.1 (about to be released in a few minutes) you can now pass raw: true to get raw fetch response so you can run your own methods on it, e.g. res.json() or res.arrayBuffer()

[niftylettuce]

Sorry I meant v2.0.2+***