react-native: [60.3] fetch issue [unable to parse json, unexpected token in json at position 1]

React Native version: 0.60.3

Steps To Reproduce

  1. upgrade react native to 0.60.3 and clean node modules and install it again
  2. send a request with fetch

there will be error like this: unexpected token o in json at position 1

and I investigated for issue and it happens because in whatwg-fetch library in line 492 support.blob will be true and the response from xhr will be Blob so in fetch response.json() will fail because response is Blob not stringified json

there are some hotfixes, but I don’t know exact solution for this

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 44
  • Comments: 73 (1 by maintainers)

Most upvoted comments

For us, it is an issue with ‘Network Inspect’ in the debugger: https://github.com/jhen0409/react-native-debugger/issues/365

Disabling that fixes this issue.

Hi! Promise object can be handled with…

.then((response) => response.json())
.then((responseJson) => {
   //HANDLE RESPONSE HERE
}

sadly 0.60.5 did not fix this for me

Was having the same issue (in Andorid release version), in my case, I fixed it by adding android:usesCleartextTraffic="true" to AndroidManifest.xml , more info https://github.com/facebook/react-native/issues/24627

hope it helps !

This seems rather major, with basic fetch functionality just being completely broken after spending a lot of time on the 0.60 upgrade. Looking forward to an ETA on this. In the meantime, I’d also take a hotfix, I haven’t been able to find one yet.

you can somehow disable blob support in your project, because in whatwg-fetch it’s checking support.blob 😃 it’s not good one but you can temporary do global.Blob = null in your init

I fixed this by using this code in componentDidMount in my app.js before I do any calls. https://github.com/jhen0409/react-native-debugger/issues/382#issuecomment-544226529

It does seem that this is a dependancy issue (I think). When I commented the line of code that @YanYuanFE mentioned a few comments prior. All of my calls work as intended. But this workaround is not a good one since you have to do this every time you delete node_modules.

The ticket has been labelled as a bug, and therefore has been found to be one. What’s the point in making claims about similar symptoms? We’re better software developers than that! It’s clearly an issue, based on the number of reactions on the ticket, and it’s the first time that I have come across the symptoms. Defending it by pulling out an issue from 3 years ago does nothing but create confusion and perhaps embarrassment on your part too 😄

@skurgansky-sugarcrm Don’t spread fake news on a confirmed issue. This is not about using devtools, and it’s also not about migration, and it definitely has nothing to do with autolinking. As @hunzalashakeel1996 and others have mentioned. This happens on creating a new app from scratch as well, which pretty much rules out all other options anyway.

I found a workaround by disabling Blob support in fetch: edit node_modules/whatwg-fetch/fetch.js and node_modules/react-native/node_modules/whatwg-fetch/fetch.js and node_modules/react-native/node_modules/whatwg-fetch/dist/fetch.umd.js

at the top of the files edit the support variable: replace: var support = { searchParams: ‘URLSearchParams’ in self, iterable: ‘Symbol’ in self && ‘iterator’ in Symbol, blob: ‘FileReader’ in self && ‘Blob’ in self && (function() { try { new Blob() return true } catch (e) { return false } })(), formData: ‘FormData’ in self, arrayBuffer: ‘ArrayBuffer’ in self }

with: var support = { searchParams: ‘URLSearchParams’ in self, iterable: ‘Symbol’ in self && ‘iterator’ in Symbol, blob: false, formData: ‘FormData’ in self, arrayBuffer: ‘ArrayBuffer’ in self }

This seems rather major, with basic fetch functionality just being completely broken after spending a lot of time on the 0.60 upgrade. Looking forward to an ETA on this. In the meantime, I’d also take a hotfix, I haven’t been able to find one yet.

node_modules/whatwg-fetch/dist/fetch.umd.js

if ('responseType' in xhr && support.blob) {
        // xhr.responseType = 'blob';
}

debug and release work fine.

“react”: “16.8.3”, “react-native”: “0.59.9”,

app // global.XMLHttpRequest = global.originalXMLHttpRequest // ? global.originalXMLHttpRequest // : global.XMLHttpRequest // global.FormData = global.originalFormData // ? global.originalFormData // : global.FormData

fetch // if (window.FETCH_SUPPORT) { // // it’s RNDebugger only to have // window.FETCH_SUPPORT.blob = false // } else { // /* // * Set FETCH_SUPPORT to false is just work for fetch. // * If you’re using another way you can just use the native Blob and remove the else statement // */ // global.Blob = global.originalBlob ? global.originalBlob : global.Blob; // global.FileReader = global.originalFileReader // ? global.originalFileReader // : global.FileReader // }

then

Enable Network Inspect

it seemed to work fine for me

@kbrandwijk Have you been able to find a fix?

fetch stops working for us after using a AsyncStorage.setItem operation in 0.60.4, if we skip that, fetch works as expected.

We have posted a reproducible test scenario here: https://github.com/react-native-community/async-storage/issues/174

We are not entirely sure if this is something that has to be fixed on the react-native or on the async-storage side, but this defect started happening with 0.60.x, which is why I’m linking this thread.

Hoping for some insightful feedback.

I tried the global.Blob workaround, and it seemed to work fine in debug mode, but somehow does not work in release mode…

No, thanks to unattended issues like this, 0.60.x is NOT suitable for production. It is beyond me why these things are abandoned like this.

I totally agree. If you are going to patch whatwg-fetch, at least make the change to this line to fix the usage of Blobs. To simply override Blob support is not constructive in the slightest.

This is absolutely not a workaround, most especially if you need to work with blobs at some point in your application. I understand that facebook’s team must have a ton of work to do, but this is a very major issue and has been there for over one month now, we need this to be fixed in order to upgrade to RN 0.60. Hope they release 0.60.5 with a fix for this very soon 😐

I still have this issue with RN 0.63.4 and React Native Debugger 0.11.5

image

Same issue on 0.60.5

setting global.Blob = null is not an option for me because other aspects of my app depend on it.

So I replaced all uses of fetch with a third party library for now. But this is most definitely a react-native bug and should be fixed as soon as possible.

XHR returning a Blob is not the issue. It’s the fact that the check for whether or not the response is a Blob here is trivially failing. It appears that xhr is using its own Blob prototype compared to the globally defined Blob. I wouldn’t have a clue on how to resolve.

@kennym That’s a workaround at best, and it definitely doesn’t fix this issue.

Can this issue be closed @MasoudAlali ?

I don’t see why the same issue could not appear again after a lot of version changes. I would say the issue is not “exists since 0.24.1”, but rather “reappears after many versions”. Same error message does not necessarily entails the same bug in the same position of the codebase as well. Many things could be different during runtime.

@dwoniu It seems to me that this is an issue related to react-native@0.60.X+ versions only…

Same issue for me on RN 0.60.4 as well. Did not find any viable solution yet.

just updated to RN 0.60.4, I can confirm that I receive a blob when I used to receive a stringified json before. Fetch is unusable in its current state, thus making RN 0.60.4 unusable aswell. I will wait for a fix

Experiencing the same problem in 0.60.4

/cc @lklepner