You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
The text was updated successfully, but these errors were encountered:
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.
Right now, a call to
endpoint.initiate(..., { subscribe: false })
has the following behaviour: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 returnvoid
. 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".
The text was updated successfully, but these errors were encountered: