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
- upgrade react native to 0.60.3 and clean node modules and install it again
- 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)
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…
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"
toAndroidManifest.xml
, more info https://github.com/facebook/react-native/issues/24627hope it helps !
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 doglobal.Blob = null
in your initI 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
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 theelse
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 aAsyncStorage.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 theasync-storage
side, but this defect started happening with0.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
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 thatxhr
is using its ownBlob
prototype compared to the globally definedBlob
. 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