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

Proper handling of non-subscribing initiate calls. #1282

Closed
phryneas opened this issue Jul 11, 2021 · 2 comments
Closed

Proper handling of non-subscribing initiate calls. #1282

phryneas opened this issue Jul 11, 2021 · 2 comments
Labels
bug Something isn't working rtk-query

Comments

@phryneas
Copy link
Member

Right now, a call to endpoint.initiate(..., { subscribe: false }) has the following behaviour:

  • dispatches pending, does not create a cache entry
  • dispatches fulfilled, updates cache entry if one exists
  • returns a promise of the result of selector(...)(getState())

While this is great for just updating an existing state value without actually subscribing (we use it for refetch), it will return an uninitialized state if there never was a cache entry before. That part, I would consider a bug.

We could have it return the fulfilled action itself (#1277 would guarantee that we always have one of those, even in "skipped, because pending" scenarios), but that would change the general return value.

We could also just change the signature of { subscribe: false } to always return void. I would consider that valid, too.

In both of these cases, we should probably change LazyQuery in #1280 to always subscribe to state. Since that was never properly exposed and a bug at the given time, that could still be a "bug fix" and not a "breaking change".

@phryneas phryneas added the bug Something isn't working label Jul 11, 2021
@bever1337
Copy link
Contributor

bever1337 commented Jan 18, 2022

I found this ticket because I was trying to find any documentation on what { subscribe: false } actually does. I was looking for a solution that solved "execute and resolve this endpoint once, automatically clean up (or do not create) any query subscriptions."

We could also just change the signature of { subscribe: false } to always return void. I would consider that valid, too.

I think this change would mean that { subscribe: false } could not be used to create a "once" behavior from RTKQ endpoints. Since that is a feature I personally want, I am glad to make the PR if you can please clarify the alternative solution you'd like to see.

While this is great for just updating an existing state value without actually subscribing (we use it for refetch), it will return an uninitialized state if there never was a cache entry before. That part, I would consider a bug.

This tracks. The necessary change is not to initialize cache when there are no subscriptions.

We could have it return the fulfilled action itself (#1277 would guarantee that we always have one of those, even in "skipped, because pending" scenarios), but that would change the general return value.

This is where I am confused. Can you please explain what the type change is?

I don't want to unfairly promote the changes I want, so please let me know if the preferred solution is to return void. I am still glad to contribute. Thanks for your help.

@markerikson
Copy link
Collaborator

Done in 2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working rtk-query
Projects
None yet
Development

No branches or pull requests

3 participants