dispatching abortRequests without a requestKey should abort all requests

[iwan-uschka]

Taking the example from https://redux-requests.klisiczynski.com/docs/api-reference/abort-requests. If i call

dispatch(abortRequests([FETCH_BOOKS]));

i am not able to abort requests FETCH_BOOKS having a specific requestKey. Is this the wanted behaviour or a bug?

In my case i dispatch FETCH_BOOKS several times in a row with a different requestKey but want to abort all requests by dispatching abortRequests once without having to know and to set the request keys being used.

[klis87]

@iwan-uschka to abort with requestKey you would need to use this API:
dispatch(abortRequests([{ requestType: FETCH_BOOK, requestKey: '1' }, { requestType: FETCH_BOOK, requestKey: '2' }]));
But indeed you need to know those.

So this is like feature request, we could support for example dispatch(abortRequests([{ requestType: FETCH_BOOK, requestKey: '*' }]); or sth, or just indeed dispatch(abortRequests([FETCH_BOOKS]));

But I feel that maybe you need something else, maybe you should use batched request? See https://redux-requests.klisiczynski.com/docs/tutorial/2-batch-requests

[iwan-uschka]

Thx @klis87 for getting back on this one.

In my scenario the user can load items of several categories manually by clicking on the specific category links. Depending on the network situation categories can load simultaneously. The calls need to be canceled if the user is gonna leave the view. Batched requests doesn't seem to fit in here but thx for the hint.

I thought the easy way initially about canceling the requests: cancel all no matter what. And it would have been nice to just call something like dispatch(abortRequests([FETCH_BOOKS])). But in the end i came to the conclusion to cache the requestKey and cancel the requests using their related requestKey. Way more clean.

I created this ticket anyway, not as a feature request but as a bug report because i thought https://redux-requests.klisiczynski.com/docs/api-reference/abort-requests/ would tell me in a top down order (hierarchically) how to cancel requests (globally to specifically) and dispatch(abortRequests([FETCH_BOOKS])) would just cancel all the FETCH_BOOKS related requests regardless of the requestKey or other settings.

So i don't wanna ask to implement this as a feature (for me 🙃 ). But feel free to do so or feel free to update the docs like

// abort FETCH_BOOKS without any requestKey or ...???any other property???
dispatch(abortRequests([FETCH_BOOKS]));

Cheers & Thx!!!

[klis87]

@iwan-uschka yes, batched requests wont fit, they are dedicated for a scenario when you need to make several requests at the same time, but if situation is dynamic or if you need to fetch more data gradually, then requestKey is better.

Anyway, you don't need cache used keys. You can derive them from the state.I won't test this, but I guess sth like that will work:

const getUsedRequestsKeys = (state, { queryType }) =>
  Object.keys(state.requests.queries).filter(v => v.startsWith(queryType)).map(v => v.replace(queryType, ''));

You could do similary thing for mutations.

[iwan-uschka]

Hey @klis87 thx for your response. I must admit i don't know what state you mean here. But no big deal, i already use a cache ref object in the specific component, which was easy to extend for this use case.

Feel free to close this ticket if you decide not to change the behaviour of dispatch(abortRequests([ACTION_NAME])); to abort all requests with or without requestKey having set.

[klis87]

@iwan-uschka just global redux state, suggested getUsedRequestsKeys is just normal redux selector, you would use it like getQuery from this library

[iwan-uschka]

Always having "store" in mind when talking about redux and "state" when talking about components. Thx for pointing that out.