本文整理汇总了TypeScript中apollo-link.fromError函数的典型用法代码示例。如果您正苦于以下问题:TypeScript fromError函数的具体用法?TypeScript fromError怎么用?TypeScript fromError使用的例子?那么恭喜您, 这里精选的函数代码示例或许可以为您提供帮助。
在下文中一共展示了fromError函数的4个代码示例,这些例子默认根据受欢迎程度排序。您可以为喜欢或者感觉有用的代码点赞,您的评价将有助于系统推荐出更棒的TypeScript代码示例。
示例1: it
it('calls unsubscribe on the appropriate downstream observable', async () => {
const retry = new RetryLink({
delay: { initial: 1 },
attempts: { max: 2 },
});
const data = { data: { hello: 'world' } };
const unsubscribeStub = jest.fn();
const firstTry = fromError(standardError);
// Hold the test hostage until we're hit
let secondTry;
const untilSecondTry = new Promise(resolve => {
secondTry = {
subscribe(observer) {
resolve(); // Release hold on test.
Promise.resolve().then(() => {
observer.next(data);
observer.complete();
});
return { unsubscribe: unsubscribeStub };
},
};
});
const stub = jest.fn();
stub.mockReturnValueOnce(firstTry);
stub.mockReturnValueOnce(secondTry);
const link = ApolloLink.from([retry, stub]);
const subscription = execute(link, { query }).subscribe({});
await untilSecondTry;
subscription.unsubscribe();
expect(unsubscribeStub).toHaveBeenCalledTimes(1);
});
示例2: ApolloLink
return new ApolloLink(operation => {
let chosenURI = selectURI(operation, uri);
const context = operation.getContext();
const contextConfig = {
http: context.http,
options: context.fetchOptions,
credentials: context.credentials,
headers: context.headers,
};
//uses fallback, link, and then context to build options
const { options, body } = selectHttpOptionsAndBody(
operation,
fallbackHttpConfig,
linkConfig,
contextConfig,
);
let controller;
if (!(options as any).signal) {
const { controller: _controller, signal } = createSignalIfSupported();
controller = _controller;
if (controller) (options as any).signal = signal;
}
// If requested, set method to GET if there are no mutations.
const definitionIsMutation = (d: DefinitionNode) => {
return d.kind === 'OperationDefinition' && d.operation === 'mutation';
};
if (
useGETForQueries &&
!operation.query.definitions.some(definitionIsMutation)
) {
options.method = 'GET';
}
if (options.method === 'GET') {
const { newURI, parseError } = rewriteURIForGET(chosenURI, body);
if (parseError) {
return fromError(parseError);
}
chosenURI = newURI;
} else {
try {
(options as any).body = serializeFetchParameter(body, 'Payload');
} catch (parseError) {
return fromError(parseError);
}
}
return new Observable(observer => {
fetcher(chosenURI, options)
.then(response => {
operation.setContext({ response });
return response;
})
.then(parseAndCheckHttpResponse(operation))
.then(result => {
// we have data and can send it to back up the link chain
observer.next(result);
observer.complete();
return result;
})
.catch(err => {
// fetch was cancelled so its already been cleaned up in the unsubscribe
if (err.name === 'AbortError') return;
// if it is a network error, BUT there is graphql result info
// fire the next observer before calling error
// this gives apollo-client (and react-apollo) the `graphqlErrors` and `networErrors`
// to pass to UI
// this should only happen if we *also* have data as part of the response key per
// the spec
if (err.result && err.result.errors && err.result.data) {
// if we dont' call next, the UI can only show networkError because AC didn't
// get andy graphqlErrors
// this is graphql execution result info (i.e errors and possibly data)
// this is because there is no formal spec how errors should translate to
// http status codes. So an auth error (401) could have both data
// from a public field, errors from a private field, and a status of 401
// {
// user { // this will have errors
// firstName
// }
// products { // this is public so will have data
// cost
// }
// }
//
// the result of above *could* look like this:
// {
// data: { products: [{ cost: "$10" }] },
// errors: [{
// message: 'your session has timed out',
// path: []
// }]
// }
// status code of above would be a 401
// in the UI you want to show data where you can, errors as data where you can
//.........这里部分代码省略.........
示例3: fromError
const stub = jest.fn(() => fromError(standardError));
示例4: selectURI
const batchHandler = (operations: Operation[]) => {
const chosenURI = selectURI(operations[0], uri);
const context = operations[0].getContext();
const contextConfig = {
http: context.http,
options: context.fetchOptions,
credentials: context.credentials,
headers: context.headers,
};
//uses fallback, link, and then context to build options
const optsAndBody = operations.map(operation =>
selectHttpOptionsAndBody(
operation,
fallbackHttpConfig,
linkConfig,
contextConfig,
),
);
const loadedBody = optsAndBody.map(({ body }) => body);
const options = optsAndBody[0].options;
// There's no spec for using GET with batches.
if (options.method === 'GET') {
return fromError<FetchResult[]>(
new Error('apollo-link-batch-http does not support GET requests'),
);
}
try {
(options as any).body = serializeFetchParameter(loadedBody, 'Payload');
} catch (parseError) {
return fromError<FetchResult[]>(parseError);
}
let controller;
if (!(options as any).signal) {
const { controller: _controller, signal } = createSignalIfSupported();
controller = _controller;
if (controller) (options as any).signal = signal;
}
return new Observable<FetchResult[]>(observer => {
// the raw response is attached to the context in the BatchingLink
fetcher(chosenURI, options)
.then(parseAndCheckHttpResponse(operations))
.then(result => {
// we have data and can send it to back up the link chain
observer.next(result);
observer.complete();
return result;
})
.catch(err => {
// fetch was cancelled so its already been cleaned up in the unsubscribe
if (err.name === 'AbortError') return;
// if it is a network error, BUT there is graphql result info
// fire the next observer before calling error
// this gives apollo-client (and react-apollo) the `graphqlErrors` and `networErrors`
// to pass to UI
// this should only happen if we *also* have data as part of the response key per
// the spec
if (err.result && err.result.errors && err.result.data) {
// if we dont' call next, the UI can only show networkError because AC didn't
// get andy graphqlErrors
// this is graphql execution result info (i.e errors and possibly data)
// this is because there is no formal spec how errors should translate to
// http status codes. So an auth error (401) could have both data
// from a public field, errors from a private field, and a status of 401
// {
// user { // this will have errors
// firstName
// }
// products { // this is public so will have data
// cost
// }
// }
//
// the result of above *could* look like this:
// {
// data: { products: [{ cost: "$10" }] },
// errors: [{
// message: 'your session has timed out',
// path: []
// }]
// }
// status code of above would be a 401
// in the UI you want to show data where you can, errors as data where you can
// and use correct http status codes
observer.next(err.result);
}
observer.error(err);
});
return () => {
// XXX support canceling this request
// https://developers.google.com/web/updates/2017/09/abortable-fetch
//.........这里部分代码省略.........