Skip to content

Using "Just Fetch" ​

Throughout this guide we've shown usage of the RequestManager in context of a Store.

ts
import { Store, CacheHandler, RequestManager, Fetch } from '@warp-drive/core';

export default class AppStore extends Store {

  requestManager = new RequestManager()
    .use([Fetch])
    .useCache(CacheHandler);

}
ts
store.request({ url: '/users' })

This is because most applications will want access to features only available when using the store such as reactive-data, advanced caching, and relational mapping.

Out of the box, the entire WarpDrive experience is optimized to be small and fast. However, if all your application needs is a pipeline to help you manage requests in a conventional way (or that plus reactive promise states / reactive control flow) then its possible to use an even more minimal WarpDrive setup.

This guide covers how to do so.

Creating a RequestManager Without a Store ​

A RequestManager does not need a Store, and it is not specific to any library or framework. On its own it does not know how to fulfill a request, so register at least one handler with use. The Fetch handler executes fetch with the request options you give it.

Most apps need only one manager. Create it once and export it from a module:

app/fetch.ts
ts
import { RequestManager, Fetch } from '@warp-drive/core';

const manager = new RequestManager().use([Fetch]);

export default manager;

Then make requests with it the same way you would with store.request:

ts
import manager from './fetch';

const { content } = await manager.request({ url: '/api/users' });

The request accepts the same request options as store.request, and builders work with it too. The Future it returns has the same abort() and getStream() described in Using The Response, and you can pass it to getRequestState for reactive control flow.

ts
const future = manager.request({ url: '/api/users' });

// later, if the result is no longer needed
future.abort();

For a complete walk-through, including JSON:API builders, pagination links and error handling, see Basic Usage in the Cookbook.

What You Give Up Without the Store ​

Without a Store there is no cache, so:

  • content is whatever the last handler in the chain returns. For Fetch that is the response body parsed as JSON, not a ReactiveDocument.
  • Requests are never deduplicated or resolved from the cache, however often you make them.

This also applies when the same RequestManager is shared with a Store, including calling store.requestManager.request directly. The CacheHandler only handles requests that carry a store, and store.request is what adds it. Requests made directly with manager.request pass through the CacheHandler untouched, as described in Determining If A Request Can Use The Cache.

Writing Your Own Handlers ​

Any handler you register with use runs for a standalone manager just as it does for a Store's manager.

  • Handlers shows how to write one that transforms a response.
  • Auth Handlers shows how to add an auth header to every request.
  • Advanced Handlers covers the RequestContext API, retrying errors, handling abort and passing streams along the chain.

Released under the MIT License.