Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to abort a kfetch call. #20700

Merged
merged 5 commits into from
Jul 12, 2018
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 32 additions & 11 deletions src/ui/public/kfetch/index.js
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,16 @@ class FetchError extends Error {
}
}

export async function kfetch(fetchOptions, kibanaOptions) {
export function kfetch(fetchOptions, kibanaOptions, isAbortable = false) {
let signal;
let abort;

if (isAbortable) {
const abortController = new AbortController();
signal = abortController.signal;
abort = abortController.abort.bind(abortController);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe abstract this into a separate createAbortable method that returns { signal, abort }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea!


// fetch specific options with defaults
const { pathname, query, ...combinedFetchOptions } = merge(
{
Expand All @@ -42,8 +51,9 @@ export async function kfetch(fetchOptions, kibanaOptions) {
'Content-Type': 'application/json',
'kbn-version': metadata.version,
},
signal,
},
fetchOptions
fetchOptions,
);

// kibana specific options with defaults
Expand All @@ -57,17 +67,28 @@ export async function kfetch(fetchOptions, kibanaOptions) {
query,
});

const res = await fetch(fullUrl, combinedFetchOptions);
const fetching = new Promise(async (resolve, reject) => {
const res = await fetch(fullUrl, combinedFetchOptions);

if (!res.ok) {
let body;
try {
body = await res.json();
} catch (err) {
// ignore error, may not be able to get body for response that is not ok
if (!res.ok) {
let body;
try {
body = await res.json();
} catch (err) {
// ignore error, may not be able to get body for response that is not ok
}
reject(new FetchError(res, body));
}
throw new FetchError(res, body);

resolve(res.json());
});

if (isAbortable) {
return {
fetching,
abort,
};
}
Copy link
Member

@sorenlouv sorenlouv Jul 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about attaching abort to the promise like:

fetching.abort = abort;

That way we can also get rid of isAbortable since all requests become abortable and we don't need a secondary api (for abortable requests).

Copy link
Contributor Author

@cjcenizal cjcenizal Jul 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally considered this approach but I had a few concerns about monkey-patching a native API:

  1. If a native abort method is introduced to promises at some point in the future then we'll need to ensure it either has identical functionality, or make a decision as to whether to cut over to the official method and ensure BWC or to keep the monkey-patched method and have unexpected behavior.

  2. Monkey-patching has the potential to confuse consumers as well since this method isn't in the spec, prompting questions like "Is this really a native promise?" and "What other non-spec methods are attached to this promise?" It requires the user to understand the implementation in order to have confidence about what's changed about this promise.

These concerns are mostly based on principle so if you think it's more pragmatic to just monkey-patch the promise, let me know your thoughts because I can definitely be persuaded! OTOH if you think these concerns are worthy then I think creating a secondary API makes sense, because we're highlighting the fact that the consumer is consciously opting into secondary behavior. And realistically, do you think it will be used very often? Do we have many use cases for aborting a fetch?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are very good points. I was mostly concerned about having two APIs but as you said, there won't be many use cases for aborting fetch, and in those cases it will be a conscious effort.

I like the approach you suggested with a separate kfetchAbortable method.


return res.json();
return fetching;
}
9 changes: 9 additions & 0 deletions src/ui/public/kfetch/index.test.js
Original file line number Diff line number Diff line change
Expand Up @@ -114,4 +114,13 @@ describe('kfetch', () => {
});
});
});

describe('isAbortable', () => {
it('should return an object with a fetching promise and an abort callback', () => {
const { fetching, abort } = kfetch({ pathname: 'my/path' }, {}, true);
expect(typeof fetching.then).toBe('function');
expect(typeof fetching.catch).toBe('function');
expect(typeof abort).toBe('function');
});
});
});