Skip to content
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

Signal request #479

Merged
merged 6 commits into from
Dec 4, 2019
Merged

Signal request #479

merged 6 commits into from
Dec 4, 2019

Conversation

wheresrhys
Copy link
Owner

@wheresrhys wheresrhys commented Dec 4, 2019

Continued from #473

As implemented, it will be a breaking change for lots of people's tests because any expectation they've made on options will break if they are also using Request.

It looks like new Request() always creates a signal property (in the browser - not an issue in node-fetch). I can't expect users to always have to care about abort signals as an artefact even when they are not deliberately working with aborted fetches.

I somehow need to carry the signal in to the library on the options so it can be used successfully to abort, but avoid have default signals getting exposed on the options object when inspecting. Probably the answer is to pass signal around as a separate entity, but this involves a bit of work.

@coveralls
Copy link

coveralls commented Dec 4, 2019

Coverage Status

Coverage increased (+0.02%) to 97.137% when pulling ee581ff on signal-request into 02de2f8 on master.

@wheresrhys
Copy link
Owner Author

Turned out to be simpler than I thought as signal is not carried very deep into the library

@wheresrhys wheresrhys merged commit 67c3abb into master Dec 4, 2019
@wheresrhys wheresrhys deleted the signal-request branch January 25, 2020 16:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants