fetch: replace Proxy objects

[KhafraDev]

Should alleviate most perf regressions in #1295, I still have no idea what a filtered response is and it's most likely wrong, but all of the tests pass.

I'll add tests later... it's late here

[KhafraDev]

Needed babel-eslint for standard because it couldn't parse this properly. There's an issue on github with this solution I can pull up if you need.

[codecov-commenter]

Codecov Report

Merging #1299 (7137e03) into main (e81c48d) will decrease coverage by 0.04%.
The diff coverage is 52.00%.

@@            Coverage Diff             @@
##             main    #1299      +/-   ##
==========================================
- Coverage   94.18%   94.14%   -0.05%     
==========================================
  Files          44       44              
  Lines        4145     4148       +3     
==========================================
+ Hits         3904     3905       +1     
- Misses        241      243       +2     

Impacted Files	Coverage Δ
lib/fetch/headers.js	94.01% <44.44%> (-5.99%)	⬇️
lib/fetch/response.js	89.78% <71.42%> (+4.91%)	⬆️
lib/fetch/index.js	80.07% <0.00%> (-0.19%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e81c48d...7137e03. Read the comment docs.

[ronag]

You can’t copy.

[ronag]

A filtered object is a view on the internal object. It’s not enough to have a copy.

[ronag]

So what you need to do here is:

Implement a FilteredResponseView that acts like an explicit proxy forwarding everything except what is filtered to the internalResponse.

Implement a FiltereredHeadersListView which does the same as above. In order to do that we probably need to change so that HeadersList doesn't extend Array but instead has a array store property which you can share references to.

[KhafraDev]

That makes sense and I definitely see why you chose proxies.

I don't think a filtered response view is possible without Proxy, unless we know which keys will be set (in doing so we can then define getters or setters for each property... which might just be as slow). Headers should be possible, but I'd rather get both of these together rather than separately.

[KhafraDev]

@ronag I've thought about this quite a bit and came up with a possibly acceptable solution (I know this is an old issue...);

I think response (the internal one, not to be confused with the fetch Response) is better suited as a class. In doing so, we can easily make a "response" filtered by, for example, setting response.filtered = true. Of course it would also need some method for property lookups and handle the filtering logic there. Same could be done for HeadersList without that much change, simply by adding a .filtered property and running a pre-set filtering function if it's filtered.

However, I don't think server-environments (deno, cf) even do this filtering in the first place and I don't see the benefit of keeping it in.