-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Flow types erased for fetch
.
#29866
Comments
Hi @chrisbobbe thanks for the issue! It seems like you found a quick fix. Do you mind submitting a PR for this for review? |
With facebook/react-native#29866, `fetch` and a few of the major things it uses are totally untyped. But react-native doesn't suppress `RequestOptions` [1], so we can still use that to help make sure we're passing around the right kinds of stuff that will eventually be fed to `fetch`. It looks like we've gestured toward not allowing `params` to contain `headers`, so, make that explicit. A type-cast and a $FlowFixMe on it at the top of `getFetchParams` can fall away naturally. [1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
Sure thing! 🙂 Just sent #29926. |
With facebook/react-native#29866, `fetch` and a few of the major things it uses are totally untyped. But react-native doesn't suppress `RequestOptions` [1], so we can still use that to help make sure we're passing around the right kinds of stuff that will eventually be fed to `fetch`. It looks like we've gestured toward not allowing `params` to contain `headers`, so, make that explicit. A type-cast and a $FlowFixMe on it at the top of `getFetchParams` can fall away naturally. [1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
With facebook/react-native#29866, `fetch` and a few of the major things it uses are totally untyped. But react-native doesn't suppress `RequestOptions` [1], so we can still use that to help make sure we're passing around the right kinds of stuff that will eventually be fed to `fetch`. It looks like we've gestured toward not allowing `params` to contain `headers`, so, make that explicit. A type-cast and a $FlowFixMe on it at the top of `getFetchParams` can fall away naturally. [1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
With facebook/react-native#29866, `fetch` and a few of the major things it uses are totally untyped. But react-native doesn't suppress `RequestOptions` [1], so we can still use that to help make sure we're passing around the right kinds of stuff that will eventually be fed to `fetch`. It looks like we've gestured toward not allowing `params` to contain `headers`, so, make that explicit. A type-cast and a $FlowFixMe on it at the top of `getFetchParams` can fall away naturally. [1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
There's been a small issue with the CLA on my PR #29926 (Facebook has been unresponsive); @safaiyeh, do you mind taking a quick look if you have time? Maybe you've seen the issue before and have some advice on how to proceed? 🙂 Once this is out of the way, there will be a lower barrier for me to make more PRs. 🙂 |
With facebook/react-native#29866, `fetch` and a few of the major things it uses are totally untyped. But react-native doesn't suppress `RequestOptions` [1], so we can still use that to help make sure we're passing around the right kinds of stuff that will eventually be fed to `fetch`. Also, it looks like the functionality of `getFetchParams` would break if a caller included `headers`, so make the type not allow that. A type-cast and a $FlowFixMe on it at the top of `getFetchParams` can fall away naturally. [1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
With facebook/react-native#29866, `fetch` and a few of the major things it uses are totally untyped. But react-native doesn't suppress `RequestOptions` [1], so we can still use that to help make sure we're passing around the right kinds of stuff that will eventually be fed to `fetch`. Also, it looks like the functionality of `getFetchParams` would break if a caller included `headers`, so make the type not allow that. A type-cast and a $FlowFixMe on it at the top of `getFetchParams` can fall away naturally. [1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions. |
Go away stale-bot, there's no sign this issue has been fixed. 🙂 |
It looks like this was resolved in 6651b7c. Thanks, @panagosg7! |
Summary: The main change of this diff is in file react-native-github/interface.js. This file used to override the definitions for `fetch`, `Headers`, `Request`, `Response`, `requestAnimationFrame` of flow/lib/bom.js and type them as `any` instead. This is inconsistent with the rest of the flow library definitions that expect `Request`, for example, to be adequately typed. Overriding this defnition with `any` raises `[value-as-type]` errors in the library definitions themselves. Due to a Flow bug, these errors were silently suppressed, leading to loss of coverage. I'm trying to clean-up these errors and fix the Flow bug so that library errors are always surfaced. This diff also: * Removes 53 unused suppression comments * Adds 110 new error suppressions Changelog: [Internal] Reviewed By: pieterv Differential Revision: D25806504 fbshipit-source-id: e312bc5d64818b63c3b8b4f86dea51e13aacfac0
Description
In a fresh RN v0.63.2 project (the latest, as of writing), some lines in
node_modules/react-native/interface.js
suppress Flow type-checking forfetch
by making it (andHeaders
,Request
, andResponse
)any
.Like #22590, but the file has since been moved, in e54ecf9. Those lines first appeared in 7141948 (6fe3b2229 on the PR branch). I'm taking @ferrannp's invitation on #22590 to comment further saying the issue hasn't been fixed (though I'm blocked from posting on the same issue). Back then, as now, the issue is certainly not related to one's precise configuration (beyond using Flow instead of not using Flow), and running the repro should confirm that. 😉 Let me know if the repro fails, though.
React Native version:
Steps To Reproduce
To set up, make a new project with
react-native init
and runyarn add flow-bin@^0.122.0
(or whichever version is mentioned under[version]
in.flowconfig
.). Then insert, e.g.,fetch('https://www.google.com')
in some valid FILE at LINE and COLUMN (e.g., App.js at line 1, column 1)Then, to see the problem:
Run
yarn flow type-at-pos FILE LINE COLUMN
(e.g.,yarn flow type-at-pos App.js 1 1
)Expected Results
I expect this output:
(input: RequestInfo, init?: RequestOptions) => Promise<Response>
(or whatever Flow's internal type definitions have forfetch
at the Flow version appropriate for the RN version)Instead, I get this output:
any (explicit)
If I remove the indicated lines in
node_modules/react-native/interface.js
and rerun steps 1 and 2 above, I get the expected output.The text was updated successfully, but these errors were encountered: