Global Cache

[cescoferraro]

Great library @jamesplease ! Thanks!

I wish I could use your library as a rest replacement for Apollo. So I have the following scenario.

Let’s say I render the 2 components with the same Fetch component.

I can see that this library will not fire the same resquest twice. Which is half the way I need.

But if I doFetch one component I wish both component would reflect the changes. Am I missing something here. Can this be done already?

[jamesplease]

Hey @cescoferraro ! Thanks for opening this issue! You are totally right: that feature is definitely a necessity to replace Apollo with this library. Actually, creating an Apollo alternative was one of the things that inspired me to write this library.

(note: this issue is similar to #191 )

My plan involved 3 libraries, and React Request is one of the 3. At this time, only 2 of the 3 libraries exist.

fetch-dedupe

Caches and requests HTTP responses.

react-request

The React implementation of fetch-dedupe.

A key feature of these libraries is that they are “dumb” about the contents of the responses. They’re not trying to parse it or understand what action you’re taking. For instance, if you fetch a book with ID of 1, and then make a subsequent request to modify that same book, these libraries have no idea about this sort of thing. They don’t know that you’re working with “books,” or that two requests could be referencing the same book.

In my opinion, that feature should be handled in an additional library, one that understands the idea of “resources.” A resource has a type (like a “book”) and a unique ID. With these assumptions in place, you can start “connecting” requests together. One request might create a book; a subsequent request may modify it.

A resource store can be created that manages the different resource types in your app. I started a library that does this, but it’s unfinished, and at this time I may never finish it. It’s called Standard Resource, and you can read the current docs at https://standard-resource.js.org.

I’m still interested in finishing this overarching project, but there is a lot of work to do, and progress has slowed. Here’s the status of each of the three libraries:

fetch-dedupe

It originally didn’t handle caching. I’m actively updating it to move caching into it, and rebranding it as bestfetch. It’s almost ready for use, and should be done in a few weeks.

request-request

Since this library was created, hooks became a thing. This library really needs hooks (#199 ). I might turn my attention to this once bestfetch is released.

Standard Resource

This library is a ton of work, and I don’t have a use case for it atm, so it hasn’t been worked on in a long time.

——

Had I ever finished Standard Resource, then it would have a React integration that would use React Request under-the-hood (or a version of React Request with hooks), and I would recommend you to install that instead of React Request directly.

You can write your own store on top of this lib, though! I’ve got some code that is workable. If you’re interested I can share it with you.

Let me know if this is unclear; I know it’s a lot 😅

—-

(btw, a resource store that I created that is done is redux-resource. Keep in mind, though: that lib was created in early 2016 and I would change a lot about its API. Standard Resource is an improved version of redux-resource. There is a thread about integration this lib with redux-resource here #198 )

[cescoferraro]

@jamesplease that does sound like lots of work! but it might be overrkill to what I am trying to achive her. as you described a subscription/observable/stream-like API.

I primarly need request debouncing, global cache and staying away from redux( lol).

Debouncing seems fairly doable to achive with the right architecture. For the latter, I was thinking of hashing the props of a generic Query component and add the <hash,response> to a mobx store and passing the store response as render props

But I also do not have a use case for these, just dont know to how no one wrote something like these before. I was experimenting with apollo-link-rest, but writing a graphql schema to a rest endpoint seems hard to sell to other devs. I cant expect dev to have graphql knowledge especially if their job is dealing with REST endpoints