Update React Hook data and options from requests that have been initiated on middleware.

[georgeiliadis91]

For complex applications middleware is the way to go.
Many times you might have queries that depend to a bunch of filter params.

Adding values those on useEffects can easily lead tp spaghetti code. Not to mention all the not needed rerendering that is gonna occur.

To avoid that middleware is the go to solution we can batch all the store updates/side effects in there when the global state changes.

Currently if I call an query via .initatie() inside my middleware when this resolves. If I have a useLazyMyQuery inside a component, the data, isLoading. isFetching etc do not see, to update ever.

Current solutions include creating selectors on the api.slices (which can become tedious especially on request with a lot of args), creating dedicated slices for data.

Ideally it would be nice to have the hooks update when the query resolves. Or even have a dedicated one.

[markerikson]

useLazyQuery is implemented differently and has different behavior than the useQuery hook, so yes, that's expected. If you need the component to actually subscribe to the data as it continues to change, then you should be using the main useQuery hook. But, that does also automatically trigger the fetch itself as well.

Can you give some examples of what your app is actually doing, code-wise?

[georgeiliadis91]

Thanks for the immediate reply!

I can post some edited snippets but not exactly what I am doing here.

This is not a single case inside the application but imagine having multiple scenarios like this one.

Let's assume query and call it getCustomData.

Now this one is getting triggered via a bunch of different actions ex:

inside my middleware

case setValA.match(action):

case setValB.match(action):

case setValC.match(action):

case setValD.match(action):

case setValE.match(action):

     //custom condition logic and calculations 
     
     api.endpoints.getCustomData.initiate( ...calculatedArgs) 

Now on my component I would like to be able to subscribe to the latest item resolved from the response

const [ , {data,isFetching}] = useLazyGetCustomDataQuery();

If I remove the middleware, to implement this i ll have an effect with a bunch of dependencies, and use the trigger part of the above hook. which would be ok, if this was a single case of happening.

But I have a bunch of scenarios that this is happening with various queries, and middleware helps us keep the codebase performant and clean.

Now I can write a selector for it, but i will have to match the cache signature which is a long string of the function call or search with timestamps.

Or I can duplicate the data on the store on a dedicated reducer slice and get it from there.
I just think it would be nice if I could just grab the latest query even if the request is triggered via iniatiate().

I am also fully aware that this is not a dedicated Redux issue and it has to do with how React it self behaves with the hooks and all.

[markerikson]

it would be nice if I could just grab the latest query

I think the issue here is that RTKQ doesn't have a notion of "latest query" on a per endpoint basis. Everything is tracked by unique cache key. So, if there was getPokemon('pikachu') and getPokemon('bulbasaur'), we don't track that those two are related, that they're both the getPokemonendpoint, or thatgetPokemon('bulbasaur')came after'pikachu'`.

You can infer those from the state by making assumptions: they both start with the same cache key prefix of 'getPokemon', if you do an Object.entries().filter() you can see which one has the latest timestamp, etc. But RTKQ doesn't explicitly track that info, and we don't provide a built-in method to do cross-entry comparisons like that.

If that's specifically what you need, then probably your best option is to write a custom selector that does the entry filtering and comparisons yousrelf.

[georgeiliadis91]

I mean, that is what literally one of my suggested work arounds, I just thought it would be nice to not go around digging the cache for timestamps and cache keys.

Either way this is why I opened this as a discussion and not an issue, cause I would like to know if this seems like a good idea to be added down the line since in my own personall experience. A lot of colleagues that like to use middleware for large applications in order to extract the complexity there, encounter this same issue.

Thanks for your input Mark!