Supply custom fetch() implementation about react-refetch HOT 11 CLOSED

Have you tried this: https://github.com/werk85/fetch-intercept ?

from react-refetch.

That's interesting, but not much more than my code block above. It acts globally, so it doesn't provide the ability to set interceptors or modifiers or proxies or whatnot on a per-connect basis, which is really what I wish for.

from react-refetch.

It also doesn't play great with libraries or other parts of my code that use fetch but shouldn't be affected by the modifications I make for react-refetched components.

from react-refetch.

Originally, I was pretty opposed to having something like this, but I'm starting to warm up the idea especially as since there's conflicting ideas around how pre and post processing should work and having more flexibility for isomorphic fetch and other fetch implementions. How are you imagining the you'd configure something like this? Some kind of fetch-provider you'd pass in as an argument to connect()?

from react-refetch.

^{(Yes, I was reluctant at first, seeing replacing fetch as a nasty hack, but with further thought, the fetch interface is quite neat and simple, and I can definitely see a small ecosystem of stack-agnostic libraries that override fetch. Like gulp and node streams ubiquitised the Pipe Transform as building block for anything, and React got the connect() pattern, and ES7 brings @decorators, and express/rack made server middleware essential, so could fetch middleware become another such pattern and building block. Or maybe that's just wishful thinking.)}

Ok, that is tricky. I originally knee-jerked like "just add it to the options obj— ah" but there's no options object. Your API is really clean! 👍

Just for arguments sake, we could add it to the main argument but uuugh so ugly:

connect(props => ({
  fetchProvider: customFetch,
// or maybe:
  _fetch: customFetch,
// yeah, nah.
  usersFetch: {
    url: `/users`,
    then: (users) => ({
      value: users.filter(u => u.verified)
    })
  }
}))(Users)

I guess the two cleanest ways would be:

As second argument to connect()

connect(props => ({
  usersFetch: {
    url: `/users`,
    then: (users) => ({
      value: users.filter(u => u.verified)
    })
  }
}), customFetch)(Users)

Or with an options object, maybe:

connect(props => ({ ... }), { customFetch })

That may introduce a slippery slope / precedent of adding options, though, which may be against the aesthetics / goals for this API.

As argument to static method on connect:

connect.withFetch(customFetch)(props => ({
  usersFetch: {
    url: `/users`,
    then: (users) => ({
      value: users.filter(u => u.verified)
    })
  }
}))(Users)

Probably more idiomatic like:

import React, { Component } from 'react'
import { connect, PromiseState } from 'react-refetch'
import { usersFetch } from './fetchProxies'
const refetch = connect.withFetch(usersFetch)

class Users extends Component { ... }

export default refetch(props => ({
  usersFetch: {
    url: `/users`,
    then: (users) => ({
      value: users.filter(u => u.verified)
    })
  }
}))(Users)

My preference is slightly for the second form, as it makes it really explicit and self-descriptive (in a way that a second argument won't), without adding an options object. I'm not too attached to the .withFetch name, though, but naming is hard.

from react-refetch.

FWIW, there is actually is an options hash, but it is currently only used for withRef and I'm probably going to drop that (just make it always available).

I kind of like that last option. I'm really liking the chainability of connect.withFetch, and thinking that it could be used for other options as well in the future.

Side note, this could also help with improving testability because fetch could be dependency injected. From my dabblings with getting isomorphic fetch to work, I think the hardest thing here is going to getting the tests to work because of weirdness with global objects. That stuff needs to be cleaned up anyway, and maybe this is a good opportunity to do that.

@passcod Would you be interested drafting a PR for this?

from react-refetch.

Absolutely! I'll get on it this weekend.

from react-refetch.

@passcod Cool, and feel free to open the PR sooner than later and add the "WIP/DO NOT MERGE" label if you want feedback before you get too far.

from react-refetch.

Definitely, thanks for suggesting it :)

from react-refetch.

Closed by #76 and release in v1.0.0-beta.0

from react-refetch.

🎉 📦

from react-refetch.