Issue 75: Fetch cannot be mocked

[farmisen]

Came here to report it and saw @cevou did it a few days ago (#75). So here is a very simple PR to fix this problem.

Stop importing fetch from isomorphic-fect to rely on the globally registered fetch function.

[cevou]

Thanks for creating the PR. Hope this gets merged soon.

[coveralls]

Coverage remained the same at 100.0% when pulling baf3b4c on farmisen:issue_75_Fetch_cannot_be_mocked into e72ac27 on agraboso:master.

[nwwells]

Not a fan: depending on globals is an anti-pattern

[cevou]

By definition the Fetch API provides a global function.

It (...) provides a global fetch() method that provides an easy, logical way to fetch resources asynchronously across the network.

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
https://fetch.spec.whatwg.org/

[benpickles]

I wonder whether requiring a fetch polyfill at all should be left to the user - for instance I'm already using whatwg-fetch as I haven't yet implemented server-side rendering. Either way my app may only require supporting modern browsers in which case this just adds to the download weight.

In which case isomorphic-fetch should be moved to devDependencies as it's then only required for testing.

[alexanderchr]

Definitely, it should be up to the user to supply their favourite fetch polyfill. A library should be indifferent to whether that happens to be whatwg-fetch, node-fetch or a native browser implementation.

An option to avoid globals would be to allow the user to supply a fetch implementation when creating the middleware.

[nwwells]

@alexanderchr see #58

[alexanderchr]

@nwwells Right, way ahead of me. Sorry for not reading before typing.

And it is indeed a much better solution. What is blocking it from being merged? @agraboso

[agraboso]

I much prefer #58 (so I'm closing this — thanks though, @farmisen). I probably won't merge that one either though because I'm thinking of allowing an object of options at creation time, which would allow not only a custom fetch but also other customizations. One of those has already been requested in #62 (allowing a root URL, which I find more than reasonable). But there's the possibility that somebody will come up with a valid reason for further customization, so I'd rather have a way of adding it without changing the API for those people that don't need it.

[migueloller]

Hey @agraboso, how far away are we from having an object of options at creation time?

[seethroughdev]

There are several issues and PRs offering solutions. Is there any progress towards this? Building @farmisen version works fine for me in testing.

@agraboso can you post an update with your thoughts?

[adam8810]

What is the status of the repo? It seems to be pretty stagnant now.