@ember-data-mirror/request 5.6.0-alpha.4 → 5.6.0-alpha.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js CHANGED
@@ -1,683 +1,2 @@
1
- import { setLogging, getRuntimeConfig } from '@warp-drive-mirror/core-types/runtime';
2
- import { macroCondition, getGlobalConfig, importSync } from '@embroider/macros';
3
- import { peekUniversalTransient, setUniversalTransient } from '@warp-drive-mirror/core-types/-private';
4
- import { I as IS_CACHE_HANDLER, a as assertValidRequest, e as executeNextHandler, g as getRequestResult, u as upgradePromise, s as setPromiseResult, c as clearRequestResult } from "./debug-CyVgT8K4.js";
5
- export { b as createDeferred, d as getPromiseResult } from "./debug-CyVgT8K4.js";
6
-
7
- /**
8
- * ```js
9
- * import RequestManager from '@ember-data-mirror/request';
10
- * ```
11
- *
12
- * A RequestManager provides a request/response flow in which configured
13
- * handlers are successively given the opportunity to handle, modify, or
14
- * pass-along a request.
15
- *
16
- * ```ts
17
- * interface RequestManager {
18
- * request<T>(req: RequestInfo): Future<T>;
19
- * }
20
- * ```
21
- *
22
- * For example:
23
- *
24
- * ```ts
25
- * import RequestManager from '@ember-data-mirror/request';
26
- * import Fetch from '@ember-data-mirror/request/fetch';
27
- * import Auth from 'ember-simple-auth/ember-data-handler';
28
- * import Config from './config';
29
- *
30
- * const { apiUrl } = Config;
31
- *
32
- * // ... create manager
33
- * const manager = new RequestManager().use([Auth, Fetch]);
34
- *
35
- * // ... execute a request
36
- * const response = await manager.request({
37
- * url: `${apiUrl}/users`
38
- * });
39
- * ```
40
- *
41
- * ### Futures
42
- *
43
- * The return value of `manager.request` is a `Future`, which allows
44
- * access to limited information about the request while it is still
45
- * pending and fulfills with the final state when the request completes.
46
- *
47
- * A `Future` is cancellable via `abort`.
48
- *
49
- * Handlers may optionally expose a `ReadableStream` to the `Future` for
50
- * streaming data; however, when doing so the future should not resolve
51
- * until the response stream is fully read.
52
- *
53
- * ```ts
54
- * interface Future<T> extends Promise<StructuredDocument<T>> {
55
- * abort(): void;
56
- *
57
- * async getStream(): ReadableStream | null;
58
- * }
59
- * ```
60
- *
61
- * ### StructuredDocuments
62
- *
63
- * A Future resolves with a `StructuredDataDocument` or rejects with a `StructuredErrorDocument`.
64
- *
65
- * ```ts
66
- * interface StructuredDataDocument<T> {
67
- * request: ImmutableRequestInfo;
68
- * response: ImmutableResponseInfo;
69
- * content: T;
70
- * }
71
- * interface StructuredErrorDocument extends Error {
72
- * request: ImmutableRequestInfo;
73
- * response: ImmutableResponseInfo;
74
- * error: string | object;
75
- * }
76
- * type StructuredDocument<T> = StructuredDataDocument<T> | StructuredErrorDocument;
77
- * ```
78
- *
79
- * @class RequestManager
80
- * @public
81
- */
82
- class RequestManager {
83
- #handlers = [];
84
-
85
- /**
86
- * A map of pending requests from request.id to their
87
- * associated CacheHandler promise.
88
- *
89
- * This queue is managed by the CacheHandler
90
- *
91
- * @internal
92
- */
93
-
94
- constructor(options) {
95
- Object.assign(this, options);
96
- this._pending = new Map();
97
- this._deduped = new Map();
98
- }
99
-
100
- /**
101
- * Register a handler to use for primary cache intercept.
102
- *
103
- * Only one such handler may exist. If using the same
104
- * RequestManager as the Store instance the Store
105
- * registers itself as a Cache handler.
106
- *
107
- * @public
108
- * @param {Handler[]} cacheHandler
109
- * @return {ThisType}
110
- */
111
- useCache(cacheHandler) {
112
- if (macroCondition(getGlobalConfig().WarpDriveMirror.env.DEBUG)) {
113
- if (this._hasCacheHandler) {
114
- throw new Error(`\`RequestManager.useCache(<handler>)\` May only be invoked once.`);
115
- }
116
- if (Object.isFrozen(this.#handlers)) {
117
- throw new Error(`\`RequestManager.useCache(<handler>)\` May only be invoked prior to any request having been made.`);
118
- }
119
- this._hasCacheHandler = true;
120
- }
121
- cacheHandler[IS_CACHE_HANDLER] = true;
122
- this.#handlers.unshift(cacheHandler);
123
- return this;
124
- }
125
-
126
- /**
127
- * Register handler(s) to use when a request is issued.
128
- *
129
- * Handlers will be invoked in the order they are registered.
130
- * Each Handler is given the opportunity to handle the request,
131
- * curry the request, or pass along a modified request.
132
- *
133
- * @public
134
- * @param {Handler[]} newHandlers
135
- * @return {ThisType}
136
- */
137
- use(newHandlers) {
138
- const handlers = this.#handlers;
139
- if (macroCondition(getGlobalConfig().WarpDriveMirror.env.DEBUG)) {
140
- if (Object.isFrozen(handlers)) {
141
- throw new Error(`Cannot add a Handler to a RequestManager after a request has been made`);
142
- }
143
- if (!Array.isArray(newHandlers)) {
144
- throw new Error(`\`RequestManager.use(<Handler[]>)\` expects an array of handlers, but was called with \`${typeof newHandlers}\``);
145
- }
146
- newHandlers.forEach((handler, index) => {
147
- if (!handler || typeof handler !== 'object' || typeof handler.request !== 'function') {
148
- throw new Error(`\`RequestManager.use(<Handler[]>)\` expected to receive an array of handler objects with request methods, by the handler at index ${index} does not conform.`);
149
- }
150
- });
151
- }
152
- handlers.push(...newHandlers);
153
- return this;
154
- }
155
-
156
- /**
157
- * Issue a Request.
158
- *
159
- * Returns a Future that fulfills with a StructuredDocument
160
- *
161
- * @public
162
- * @param {RequestInfo} request
163
- * @return {Future}
164
- */
165
- request(request) {
166
- const handlers = this.#handlers;
167
- if (macroCondition(getGlobalConfig().WarpDriveMirror.env.DEBUG)) {
168
- if (!Object.isFrozen(handlers)) {
169
- Object.freeze(handlers);
170
- }
171
- assertValidRequest(request, true);
172
- }
173
- const controller = request.controller || new AbortController();
174
- if (request.controller) {
175
- delete request.controller;
176
- }
177
- const requestId = peekUniversalTransient('REQ_ID') ?? 0;
178
- setUniversalTransient('REQ_ID', requestId + 1);
179
- const context = {
180
- controller,
181
- response: null,
182
- stream: null,
183
- hasRequestedStream: false,
184
- id: requestId,
185
- identifier: null
186
- };
187
- const promise = executeNextHandler(handlers, request, 0, context);
188
-
189
- // the cache handler will set the result of the request synchronously
190
- // if it is able to fulfill the request from the cache
191
- const cacheResult = getRequestResult(requestId);
192
- if (macroCondition(getGlobalConfig().WarpDriveMirror.env.TESTING)) {
193
- if (!request.disableTestWaiter) {
194
- const {
195
- waitForPromise
196
- } = importSync('@ember/test-waiters');
197
- const newPromise = waitForPromise(promise);
198
- const finalPromise = upgradePromise(newPromise.then(result => {
199
- setPromiseResult(finalPromise, {
200
- isError: false,
201
- result
202
- });
203
- clearRequestResult(requestId);
204
- return result;
205
- }, error => {
206
- setPromiseResult(finalPromise, {
207
- isError: true,
208
- result: error
209
- });
210
- clearRequestResult(requestId);
211
- throw error;
212
- }), promise);
213
- if (cacheResult) {
214
- setPromiseResult(finalPromise, cacheResult);
215
- }
216
- return finalPromise;
217
- }
218
- }
219
-
220
- // const promise1 = store.request(myRequest);
221
- // const promise2 = store.request(myRequest);
222
- // promise1 === promise2; // false
223
- // either we need to make promise1 === promise2, or we need to make sure that
224
- // we need to have a way to key from request to result
225
- // such that we can lookup the result here and return it if it exists
226
- const finalPromise = upgradePromise(promise.then(result => {
227
- setPromiseResult(finalPromise, {
228
- isError: false,
229
- result
230
- });
231
- clearRequestResult(requestId);
232
- return result;
233
- }, error => {
234
- setPromiseResult(finalPromise, {
235
- isError: true,
236
- result: error
237
- });
238
- clearRequestResult(requestId);
239
- throw error;
240
- }), promise);
241
- if (cacheResult) {
242
- setPromiseResult(finalPromise, cacheResult);
243
- }
244
- return finalPromise;
245
- }
246
- static create(options) {
247
- return new this(options);
248
- }
249
- }
250
-
251
- /**
252
- *
253
- <p align="center">
254
- <img
255
- class="project-logo"
256
- src="https://raw.githubusercontent.com/emberjs/data/4612c9354e4c54d53327ec2cf21955075ce21294/ember-data-logo-light.svg#gh-light-mode-only"
257
- alt="EmberData RequestManager"
258
- width="240px"
259
- title="EmberData RequestManager"
260
- />
261
- </p>
262
-
263
- <p align="center">⚡️ a simple abstraction over fetch to enable easy management of request/response flows</p>
264
-
265
- This package provides [*Ember*‍**Data**](https://github.com/emberjs/data/)'s `RequestManager`, a framework agnostic library that can be integrated with any Javascript application to make [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) happen.
266
-
267
- - [Installation](#installation)
268
- - [Basic Usage](#🚀-basic-usage)
269
- - [Architecture](#🪜-architecture)
270
- - [Usage](#usage)
271
- - [Making Requests](#making-requests)
272
- - [Using The Response](#using-the-response)
273
- - [Request Handlers](#handling-requests)
274
- - [Handling Errors](#handling-errors)
275
- - [Handling Abort](#handling-abort)
276
- - [Stream Currying](#stream-currying)
277
- - [Automatic Currying](#automatic-currying-of-stream-and-response)
278
- - [Using as a Service](#using-as-a-service)
279
- - [Using with `@ember-data-mirror/store`](#using-with-ember-datastore)
280
- - [Using with `ember-data`](#using-with-ember-data)
281
-
282
- ---
283
-
284
- ## Installation
285
-
286
- Install using your javascript package manager of choice. For instance with [pnpm](https://pnpm.io/)
287
-
288
- ```no-highlight
289
- pnpm add @ember-data-mirror/request
290
- ```
291
-
292
- ---
293
-
294
- ## 🚀 Basic Usage
295
-
296
- A `RequestManager` provides a request/response flow in which configured handlers are successively given the opportunity to handle, modify, or pass-along a request.
297
-
298
- The RequestManager on its own does not know how to fulfill requests. For this we must register at least one handler. A basic `Fetch` handler is provided that will take the request options provided and execute `fetch`.
299
-
300
- ```ts
301
- import RequestManager from '@ember-data-mirror/request';
302
- import Fetch from '@ember-data-mirror/request/fetch';
303
- import { apiUrl } from './config';
304
-
305
- // ... create manager and add our Fetch handler
306
- const manager = new RequestManager()
307
- .use([Fetch]);
308
-
309
- // ... execute a request
310
- const response = await manager.request({
311
- url: `${apiUrl}/users`
312
- });
313
- ```
314
-
315
- ---
316
-
317
- ## 🪜 Architecture
318
-
319
- A `RequestManager` receives a request and manages fulfillment via configured handlers. It may be used standalone from the rest of *Ember*‍**Data** and is not specific to any library or framework.
320
-
321
- Each handler may choose to fulfill the request using some source of data or to pass the request along to other handlers.
322
-
323
- The same or a separate instance of a `RequestManager` may also be used to fulfill requests issued by [*Ember*‍**Data**{Store}](https://github.com/emberjs/data/tree/main/packages/store)
324
-
325
- When the same instance is used by both this allows for simple coordination throughout the application. Requests issued by the Store will use the in-memory cache
326
- and return hydrated responses, requests issued directly to the RequestManager
327
- will skip the in-memory cache and return raw responses.
328
-
329
- ---
330
-
331
- ## Usage
332
-
333
- ```ts
334
- const userList = await manager.request({
335
- url: `/api/v1/users.list`
336
- });
337
-
338
- const users = userList.content;
339
- ```
340
-
341
- ---
342
-
343
- ### Making Requests
344
-
345
- `RequestManager` has a single asyncronous method as it's API: `request`
346
-
347
- ```ts
348
- class RequestManager {
349
- request<T>(req: RequestInfo): Future<T>;
350
- }
351
- ```
352
-
353
- `manager.request(<RequestInfo>)` accepts an object containing the information
354
- necessary for the request to be handled successfully.
355
-
356
- These options extend the [options](https://developer.mozilla.org/en-US/docs/Web/API/fetch#parameters) provided to `fetch`, and can accept a [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request). All properties accepted by Request options and fetch options are valid.
357
-
358
- ```ts
359
- interface RequestInfo extends FetchOptions {
360
- op?: string;
361
- store?: Store;
362
-
363
- url: string;
364
- // data that a handler should convert into
365
- // the query (GET) or body (POST)
366
- data?: Record<string, unknown>;
367
-
368
- // options specifically intended for handlers
369
- // to utilize to process the request
370
- options?: Record<string, unknown>;
371
- }
372
- ```
373
-
374
- > **note**
375
- > providing a `signal` is unnecessary as an `AbortController` is automatically provided if none is present.
376
-
377
- ---
378
-
379
- #### Using the Response
380
-
381
- `manager.request` returns a `Future`, which allows access to limited information about the request while it is still pending and fulfills with the final state when the request completes and the response has been read.
382
-
383
- ```ts
384
- const usersFuture = manager.request({
385
- url: `/api/v1/users.list`
386
- });
387
- ```
388
-
389
- A `Future` is cancellable via `abort`.
390
-
391
- ```ts
392
- usersFuture.abort();
393
- ```
394
-
395
- Handlers may *optionally* expose a ReadableStream to the `Future` for streaming data; however, when doing so the handler should not resolve until it has fully read the response stream itself.
396
-
397
- ```ts
398
- interface Future<T> extends Promise<StructuredDocument<T>> {
399
- abort(): void;
400
-
401
- async getStream(): ReadableStream | null;
402
- }
403
- ```
404
-
405
- A Future resolves or rejects with a `StructuredDocument`.
406
-
407
- ```ts
408
- interface StructuredDocument<T> {
409
- request: RequestInfo;
410
- response: ResponseInfo | null;
411
- content?: T;
412
- error?: Error;
413
- }
414
- ```
415
-
416
- The `RequestInfo` specified by `document.request` is the same as originally provided to `manager.request`. If any handler fulfilled this request using different request info it is not represented here. This contract helps to ensure that `retry` and `caching` are possible since the original arguments are correctly preserved. This also allows handlers to "fork" the request or fulfill from multiple sources without the details of fulfillment muddying the original request.
417
-
418
- The `ResponseInfo` is a serializable fulfilled subset of a [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) if set via `setResponse`. If no response was ever set this will be `null`.
419
-
420
- ```ts
421
- interface ResponseInfo {
422
- headers?: Record<string, string>;
423
- ok?: boolean;
424
- redirected?: boolean;
425
- status?: HTTPStatusCode;
426
- statusText?: string;
427
- type?: 'basic' | 'cors';
428
- url?: string;
429
- }
430
- ```
431
-
432
- ---
433
-
434
- ### Request Handlers
435
-
436
- Requests are fulfilled by handlers. A handler receives the request context
437
- as well as a `next` function with which to pass along a request to the next
438
- handler if it so chooses.
439
-
440
- A handler may be any object with a `request` method. This allows both stateful and non-stateful
441
- handlers to be utilized.
442
-
443
- If a handler calls `next`, it receives a `Future` which resolves to a `StructuredDocument`
444
- that it can then compose how it sees fit with its own response.
445
-
446
- ```ts
447
-
448
- type NextFn<P> = (req: RequestInfo) => Future<P>;
449
-
450
- interface Handler {
451
- async request<T>(context: RequestContext, next: NextFn<P>): T;
452
- }
453
- ```
454
-
455
- `RequestContext` contains a readonly version of the RequestInfo as well as a few methods for building up the `StructuredDocument` and `Future` that will be part of the response.
456
-
457
- ```ts
458
- interface RequestContext<T> {
459
- readonly request: RequestInfo;
460
-
461
- setStream(stream: ReadableStream | Promise<ReadableStream>): void;
462
- setResponse(response: Response | ResponseInfo): void;
463
- }
464
- ```
465
-
466
- A basic `fetch` handler with support for streaming content updates while
467
- the download is still underway might look like the following, where we use
468
- [`response.clone()`](https://developer.mozilla.org/en-US/docs/Web/API/Response/clone) to `tee` the `ReadableStream` into two streams.
469
-
470
- A more efficient handler might read from the response stream, building up the
471
- response content before passing along the chunk downstream.
472
-
473
- ```ts
474
- const FetchHandler = {
475
- async request(context) {
476
- const response = await fetch(context.request);
477
- context.setResponse(reponse);
478
- context.setStream(response.clone().body);
479
-
480
- return response.json();
481
- }
482
- }
483
- ```
484
-
485
- Request handlers are registered by configuring the manager via `use`
486
-
487
- ```ts
488
- manager.use([Handler1, Handler2])
489
- ```
490
-
491
- Handlers will be invoked in the order they are registered ("fifo", first-in first-out), and may only be registered up until the first request is made. It is recommended but not required to register all handlers at one time in order to ensure explicitly visible handler ordering.
492
-
493
- ---
494
-
495
- #### Handling Errors
496
-
497
- Each handler in the chain can catch errors from upstream and choose to
498
- either handle the error, re-throw the error, or throw a new error.
499
-
500
- ```ts
501
- const MAX_RETRIES = 5;
502
-
503
- const Handler = {
504
- async request(context, next) {
505
- let attempts = 0;
506
-
507
- while (attempts < MAX_RETRIES) {
508
- attempts++;
509
- try {
510
- const response = await next(context.request);
511
- return response;
512
- } catch (e) {
513
- if (isTimeoutError(e) && attempts < MAX_RETRIES) {
514
- // retry request
515
- continue;
516
- }
517
- // rethrow if it is not a timeout error
518
- throw e;
519
- }
520
- }
521
- }
522
- }
523
- ```
524
-
525
- ---
526
-
527
- #### Handling Abort
528
-
529
- Aborting a request will reject the current handler in the chain. However,
530
- every handler can potentially catch this error. If your handler needs to
531
- separate AbortError from other Error types, it is recommended to check
532
- `context.request.signal.aborted` (or if a custom controller was supplied `controller.signal.aborted`).
533
-
534
- In this manner it is possible for a request to recover from an abort and
535
- still proceed; however, as a best practice this should be used for necessary
536
- cleanup only and the original AbortError rethrown if the abort signal comes
537
- from the root controller.
538
-
539
- **AbortControllers are Always Present and Always Entangled**
540
-
541
- If the initial request does not supply an [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController), one will be generated.
542
-
543
- The [signal](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) for this controller is automatically added to the request passed into the first handler.
544
-
545
- Each handler has the option to supply a new controller to the request when calling `next`. If a new controller is provided it will be automatically
546
- entangled with the root controller. If the root controller aborts, so will
547
- any entangled controllers.
548
-
549
- If an entangled controller aborts, the root controller will not abort. This
550
- allows for advanced request-flow scenarios to abort subsections of the request tree without aborting the entire request.
551
-
552
- ---
553
-
554
- #### Stream Currying
555
-
556
- `RequestManager.request` and `next` differ from `fetch` in one **crucial detail** in that the outer Promise resolves only once the response stream has been processed.
557
-
558
- For context, it helps to understand a few of the use-cases that RequestManager
559
- is intended to allow.
560
-
561
- - to manage and return streaming content (such as video files)
562
- - to fulfill a request from multiple sources or by splitting one request into multiple requests
563
- - for instance one API call for a user and another for the user's friends
564
- - or e.g. fulfilling part of the request from one source (one API, in-memory, localStorage, IndexedDB
565
- etc.) and the rest from another source (a different API, a WebWorker, etc.)
566
- - to coalesce multiple requests
567
- - to decorate a request with additional info
568
- - e.g. an Auth handler that ensures the correct tokens or headers or cookies are attached.
569
-
570
-
571
- `await fetch(<req>)` resolves at the moment headers are received. This allows for the body of the request to be processed as a stream by application
572
- code *while chunks are still being received by the browser*.
573
-
574
- When an app chooses to `await response.json()` what occurs is the browser reads the stream to completion and then returns the result. Additionally, this stream may only be read **once**.
575
-
576
- The `RequestManager` preserves this ability to subscribe to and utilize the stream by either the application or the handler – thereby delivering the full power and flexibility of native APIs – without restricting developers in ways that lead to complicated workarounds.
577
-
578
- Each handler may call `setStream` only once, but may do so *at any time* until the promise that the handler returns has resolved. The associated promise returned by calling `future.getStream` will resolve with the stream set by `setStream` if that method is called, or `null` if that method
579
- has not been called by the time that the handler's request method has resolved.
580
-
581
- Handlers that do not create a stream of their own, but which call `next`, should defensively pipe the stream forward. While this is not required (see automatic currying below) it is better to do so in most cases as otherwise the stream may not become available to downstream handlers or the application until the upstream handler has fully read it.
582
-
583
- ```ts
584
- context.setStream(future.getStream());
585
- ```
586
-
587
- Handlers that either call `next` multiple times or otherwise have reason to create multiple fetch requests should either choose to return no stream, meaningfully combine the streams, or select a single prioritized stream.
588
-
589
- Of course, any handler may choose to read and handle the stream, and return either no stream or a different stream in the process.
590
-
591
- ---
592
-
593
- #### Automatic Currying of Stream and Response
594
-
595
- In order to simplify the common case for handlers which decorate a request, if `next` is called only a single time and `setResponse` was never called by the handler, the response set by the next handler in the chain will be applied to that handler's outcome. For instance, this makes the following pattern possible `return (await next(<req>)).content;`.
596
-
597
- Similarly, if `next` is called only a single time and neither `setStream` nor `getStream` was called, we automatically curry the stream from the future returned by `next` onto the future returned by the handler.
598
-
599
- Finally, if the return value of a handler is a `Future`, we curry `content` and `errors` as well, thus enabling the simplest form `return next(<req>)`.
600
-
601
- In the case of the `Future` being returned, `Stream` proxying is automatic and immediate and does not wait for the `Future` to resolve.
602
-
603
- ---
604
-
605
- #### Using with `@ember-data-mirror/store`
606
-
607
- To have a request service unique to a Store:
608
-
609
- ```ts
610
- import Store, { CacheHandler } from '@ember-data-mirror/store';
611
- import RequestManager from '@ember-data-mirror/request';
612
- import Fetch from '@ember-data-mirror/request/fetch';
613
-
614
- class extends Store {
615
- requestManager = new RequestManager()
616
- .use([Fetch])
617
- .useCache(CacheHandler);
618
- }
619
- ```
620
-
621
- ---
622
-
623
- ### Using as a Service
624
-
625
- Some applications will desire to have a single `RequestManager` instance, which can be achieved using module-state patterns for singletons, or for [Ember](https://emberjs.com) applications by exporting the manager as a [service](https://guides.emberjs.com/release/services/).
626
-
627
- *services/request.ts*
628
- ```ts
629
- import { CacheHandler } from '@ember-data-mirror/store';
630
- import RequestManager from '@ember-data-mirror/request';
631
- import Fetch from '@ember-data-mirror/request/fetch';
632
- import Auth from 'ember-simple-auth/ember-data-handler';
633
-
634
- export default {
635
- create() {
636
- return new RequestManager()
637
- .use([Auth, Fetch])
638
- .use(CacheHandler);
639
- }
640
- }
641
- ```
642
-
643
- ---
644
-
645
- #### Using with `ember-data`
646
-
647
- If using the package [ember-data](https://github.com/emberjs/data/tree/main/packages/-ember-data),
648
- the following configuration will automatically be done in order to preserve the
649
- legacy [Adapter](https://github.com/emberjs/data/tree/main/packages/adapter) and
650
- [Serializer](https://github.com/emberjs/data/tree/main/packages/serializer) behavior.
651
- Additional handlers or a service injection like the above would need to be done by the
652
- consuming application in order to make broader use of `RequestManager`.
653
-
654
- ```ts
655
- import Store from 'ember-data-mirror/store';
656
- import { CacheHandler } from '@ember-data-mirror/store';
657
- import RequestManager from '@ember-data-mirror/request';
658
- import Fetch from '@ember-data-mirror/request/fetch';
659
- import { LegacyNetworkHandler } from '@ember-data-mirror/legacy-compat';
660
-
661
- export default class extends Store {
662
- requestManager = new RequestManager()
663
- .use([LegacyNetworkHandler, Fetch])
664
- .useCache(CacheHandler);
665
- }
666
- ```
667
-
668
- To provide a different configuration, import and extend `ember-data/store`. The
669
- default configuration will be ignored if the `requestManager` property is set,
670
- though the store will still register the CacheHandler.
671
-
672
- For usage of the store's `requestManager` via `store.request(<req>)` see the
673
- [Store](https://api.emberjs.com/ember-data/release/modules/@ember-data%2Fstore) documentation.
674
-
675
- *
676
- * @module
677
- */
678
- // @ts-expect-error adding to globalThis
679
- globalThis.setWarpDriveLogging = setLogging;
680
-
681
- // @ts-expect-error adding to globalThis
682
- globalThis.getWarpDriveRuntimeConfig = getRuntimeConfig;
683
- export { RequestManager as default, setPromiseResult };
1
+ export * from '@warp-drive/core/request';
2
+ export { RequestManager as default } from '@warp-drive/core';