You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
not sure that this is favorable or not but thought that it might be and it allows
for easier testing of the creation of responses and their properties.
Ah - it looks like this adds a named export to the actual unfetch package, which means it won't work - folks using CommonJS will have to do import('unfetch').default which is a breaking change.
Instead, if we could retrofit your work here into proper support for the Response interface, that would definitely be a justifiable export! It would be a nice step towards supporting Headers, Request and Response, something that's been on my todo list for ages.
@kalisjoshua that'll be the added export. One quick solution to check this would be to move the response function into a separate file (src/lib/response.mjs) that is imported by src/index.mjs and tests, that way it's not exported as unfetch.response.
not sure that this is favorable or not but thought that it might be and it allows
for easier testing of the creation of responses and their properties.
@kalisjoshua that'll be the added export. One quick solution to check this would be to move the response function into a separate file (src/lib/response.mjs) that is imported by src/index.mjs and tests, that way it's not exported as unfetch.response.
Interesting that the numbers are still so increased. My guess is that's because we're ending up with a closure around the two top-level functions, whereas currently there is no closure required since all functionality exists within the single unfetch(){} function (as a sort of wrapper + implementation). Perhaps that's just something that we'll be giving up.
It's interesting to look at the compiled output diff of dist/unfetch.js between the master branch and my branch. On the master branch the for loop is expanded a little but on my branch the loop is most of the body of the function. I'm still examining it to see if there is anything that can be done to bring the output sizes closer because there isn't an extra closure.
I think the biggest contributor to the bloat that I created is because of the lifting of the response function out of the scope necessitating that arguments be passed in and that also results in a more complicated clone attribute on the response object. I am able to slim the output size a slight bit; encapsulated in the most recent commit.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
not sure that this is favorable or not but thought that it might be and it allows
for easier testing of the creation of responses and their properties.