Implement ability to directly prime the cache

[ryanspradlin]

This PR implements a new prime(key, value) API that directly primes the cache with a given key and value.

This is mentioned in #2 as a way to enable building a two-way cache, but I think a more basic motivation for this API would simply be to allow cache pre-warming. Another use case I have for this is to allow creating a DataLoader subclass that implements loadAll() (https://gist.github.com/ryanspradlin/1e951a4dcf737e3fb194).

[ryanspradlin]

Looks like this build is failing right now just due to the babel-eslint/escope issue: babel/babel-eslint#243 (fixed in newest babel-eslint).

[ryanspradlin]

Here's a PR to upgrade the babel-eslint dependency: #19

[ryanspradlin]

Friendly bump -- any thoughts on this PR?

[leebyron]

Sorry for the delay on this. Last time we discussed this we were concerned about the race-condition case where a current request is already outbound when prime is called. In other words, what should the behavior of prime be the promise cache already has a value in it for the given key? It could be possible for a get, prime, get call to happen in that order such that the two subsequent gets do not result in the same value, which could cause issues.

I think the uses of building a two-index cache and pre-warming a cache are in some ways at odds with each other.

Maybe the right way is to do nothing if they key already exists? That way you would have to explicitly declare if you wanted to forcefully prime the cache with loader.clear(key).prime(key, value).

[ryanspradlin]

Apologies for the delay on my end this time. Thanks for the feedback -- that makes sense, and your suggestion sounds great to me. I've updated the PR to reflect the new logic (priming an existing key will do nothing), and updated the documentation and tests to match.

Thanks!

[coveralls]

Coverage remained the same at 100.0% when pulling 5e21df6 on ryanspradlin:features/prime into a57c44f on facebook:master.

[leebyron]

Excellent work!