Identity Request Promises

[ryanbrainard]

If value is given a Promise, the PromiseState will be pending until the value or reason is settled; otherwise, the PromiseState will be resolved immediately.

This was suggested in #92 as a possible solution to @nfcampos desire to load files like fetches. It should also be compatible the expectation @neezer had in #63 that static data loads immediately. I think this is a win-win. Thoughts?

Note, I played a little bit w/ trying to unify fetch requests and identity requests and cut down on the nested conditionals, but the meta handling was getting in the way. If someone with more Promise-foo wants to take a stab at it, feel free :) Either way, I think the way it is now reads better, even though it is a bit verbose.

[nfcampos]

I realised now that for this to be useful value has to be a function that returns a promise, instead of a promise, otherwise it will recompute every time anything about props changes, which seeing as these are potentially expensive operations (that's why they're async in the first place) is a deal breaker.

[ryanbrainard]

@nfcampos Good point. Need to think on that.

[nfcampos]

Assuming that any function that is assigned to value is a promise-returning function that we should call sounds too restrictive (I don't see a use case for using identity requests to inject a function, though, so maybe not?), another option is for this behaviour of promise identity requests to be under a new key promise. what do you think?

[nfcampos]

This is definitely not something that I need in every component but I've now hit a second situation where I'd have used this, do you think this belongs in react-refetch @ryanbrainard ?

[ryanbrainard]

@nfcampos is your previous comment still valid?

I realised now that for this to be useful value has to be a function that returns a promise, instead of a promise

Are you saying your would like this as is or wrapped in a function?

[nfcampos]

value: somethingThatReturnsPromise() works inside then, andThen, etc., in functional mappings. The only place where it might be problematic is directly as a top level request, but even then it's probably fine for most uses because we now only re-run the mapPropsToRequestsToProps function if the props changed. So I think it's fine as is, what do you think?

[ryanbrainard]

Yeah, I think that makes sense, is simpler, and more consistent. Pulling this in.