Add possibility to manually unsubscribe from useLazyQuery #2055

[damianborowy]

Related to issue #2055

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 1a40475:

Sandbox	Source
Vanilla	Configuration
Vanilla Typescript	Configuration
rsk-github-issues-example	Configuration
@examples-query-react/basic	Configuration
reduxjs/redux-toolkit	Configuration
@examples-action-listener/counter	Configuration

[netlify]

✅ Deploy Preview for redux-starter-kit-docs ready!

🔨 Explore the source changes: 1a40475

🔍 Inspect the deploy log: https://app.netlify.com/sites/redux-starter-kit-docs/deploys/6234eb2c12d4cf0008f84be1

😎 Browse the preview: https://deploy-preview-2133--redux-starter-kit-docs.netlify.app

[phryneas]

I would suggest to make unsubscribe part of the info object and maybe give it a better name. Open to suggestions.

[damianborowy]

That's some good advice, I missed the fact that info was already an object for some extra things so I can touch it without breaking anything 😄 not sure if extras is the best possible name though, waiting for further feedback!

[phryneas]

We just did a grooming of PRs and discussed this: would you be okay to to a PR for a reset method instead that unsubscribed and set the query hook back to isUninitialized?

It feels inconsistent to us that after unsubscribing, the query state will still stay in the component for another 60 seconds - or even forever, if another component is still using it.

Or do you have a good use case that would only make sense with unsubscribe, but not with reset?

[henkkasoft]

We just did a grooming of PRs and discussed this: would you be okay to to a PR for a reset method instead that unsubscribed and set the query hook back to isUninitialized?

It feels inconsistent to us that after unsubscribing, the query state will still stay in the component for another 60 seconds - or even forever, if another component is still using it.

Or do you have a good use case that would only make sense with unsubscribe, but not with reset?

This is exactly what I am looking for I think.

I am using useLazyQuery with query params given by user.
The API response is HTTP ERROR 422 when the user input is incorrectly formed.
UI will show modal of the error and then I want to recover without unmounting the component. So I would want to get rid of the isError state and the user could modify the input and trigger the query again.

Is this possible somehow already?
And if not, did I understood correctly that this PR (when unsubscribe is extended as reset) will enable this kind of usage?

[phryneas]

@henkkasoft it will not remove the value, just unsubscribe from it. It will be removed after 60 second if no other component uses it.

Maybe you are giving isError too much importance here?
As it sounds "there is an error from the server" will 100% be true until the data is sent to the server without a 422 - so maybe you just need an additional local state to control that message?

[stchristian]

Hi, I see that there was no activity on this PR for a while now. Is this still pending? I would be happy to take over this PR and implement the above mentioned reset method
@damianborowy @henkkasoft

[markerikson]

@stchristian yeah, no one has looked at this in a year. Might be best to re-create it and file a new PR with the updates

[stchristian]

@markerikson Before starting this feature, I would suggest adding a skip parameter instead of reset method, similar to useQuery() that would work the same way setting the hook to uninitialized. This way the query stays consistent with the existing interface.

[henkkasoft]

@henkkasoft it will not remove the value, just unsubscribe from it. It will be removed after 60 second if no other component uses it.

Maybe you are giving isError too much importance here? As it sounds "there is an error from the server" will 100% be true until the data is sent to the server without a 422 - so maybe you just need an additional local state to control that message?

I solved my problem earlier so that after showing input-error modal I stored startedTimeStamp so that unless it it changed the modal is not shown again. It worked nice even the reseting was not possible... until now.

My guess is that the encountered problem now is this:
Because reseting is not done the query (even in the isError state) is invalidated when somewhere in the app doing some modification invalidation of correct tag is done. Invalidation change the startedTimeStamp of the query and the input-error modal is shown again.

It is really confusing for the user that some old input error from advanced search is shown again when doing some modification elsewhere in the app. In our app the advanced search can be open in the app and still other tasks can be performed. So it is not uncommon to try to search something but fail the search and continue usage so that the latest advanced search is left open and that is why the reseting or atleast unsubscribing this lazy query would be important to be able to perform.

Any updates on this PR / issue #2055 ?

[henkkasoft]

I was able to prevent invalidation of the query in isError state by adding error check to providesTags function:
return error ? [] : ['MyTag']
Now error state queries are not invalidated when 'MyTag' is invalidated in some mutation's invalidatesTags function.

Not sure if this is still the best solution...

[markerikson]

Replaced by #4689