-
-
Notifications
You must be signed in to change notification settings - Fork 771
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
sinon fake server not working in React Native app #1051
Comments
If you are using React native you are not running in a browser, AFAIK. In that case, you won't be using native XHR either, which is what sinon is trying to replace. Correct me if I'm wrong. |
Yes, it is not a browser environment. React Native provides a polyfill for XMLHttpRequest and thus makes possible using tools like SuperAgent for data loading. Assumed sinon should be able to create a wrapper around the RN's XMLHttpRequest quite easily but it is not the case it seems... |
It would be really great to have sinon work in RN env. Can't find any tool that we could use to serve up mock data in dev by plugging into the flow as easily as it could be done in sinon.. |
You might get it to work, but it is not supported. You could supply a pull request, if you want it 😺 Regarding your last comment: |
Actually mocking network data is precisely what my team needs. We want to make sure that all code gets executed but without the necessity to have a backend ready. As you know backend work is usually a domain of another team and it is never done in time... I actually made sinon to work in RN last night. While it is not supported, it could be easily supported since xhr polyfill is there and SuperAgent runs on it without a hickup. There is one line change actually in fake_xml_http_request...as long as you set supportsCORS to true for RN (which it does support but not by way of having withCredentials) the proper FakeXMLHttpRequest is created in fakeServer.create(). Current code erroneously creates FakeXDomainRequest.. This can be defaulted to true by way of checking window.navigator.product === "ReactNative" The other fix is to polyfill window.location because in RN there is no window.location...so I hardcode
This is used by rCurrLoc in fakeServer.js and seems like default to local to http://localhost works fine for all use cases... so in fakeServer This is it....sinon runs on RN - device or browser debug.. Having this work for RN would be huge...I submitted a PR... |
I'm still seeing an error in RN with regard to this:
I'm using the latest stable Sinon - I'm just trying to use |
One way is to avoid importing the
This isn't very pretty though, so if anyone knows a nicer way I'd be glad to hear it :) |
out of curiosity - what is the RN version you are using? We have not had such issue using RN 0.26. I do not recall we used imports though... |
@simonsmith : the work @andpor done has gone into what will be the next version (2.0) of Sinon (the |
@andpor I am using @fatso83 Thanks for the suggestion. Unfortunately this throws a different error:
|
@simonsmith that error is completely unrelated to the xhr change. |
Shall I open a separate issue? |
+1 |
@GeoffreyPlitt that +1 serves no purpose. this issue is closed. there is no way of knowing if you meant to imply that you have been bitten by this bug, the #1143 bug or you wish to express a concurring opinion for something else. The "+😄" button is there for this reason, and it is also a way of doing the same with less noise ;-) |
Hi all - seeing this issue again on RN version 0.35. I'm currently using sinon@next (2.0.0-pre.4). Protocol is undefined, despite us having the default set on the ternary statement ( If this matters, using jest for testing, version 16.0.1 ( |
@jamesaspence: please fill out a separate issue report and include some reproducible code, preferably the luxury version that includes a minimal repo that recreates the issue ( |
Will do this when I get a chance. Thank you! |
I am able to require sinon but looks like the network calls through SuperAgent are not getting intercepted by signon fake server ? Using 1.17.4
The text was updated successfully, but these errors were encountered: