Streaming request

[artursvonda]

I've seen approaches for streaming updates, but this is not about it. This is about streaming request – a request that returns data partially using Server Sent Events (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events). We use it to stream for streaming GPT responses as they become available. In our case, these requests have clear start and end, they are not meant to be long-lived requests. Right now we use approach similar to web sockets, but because of that we lose "lifecycle" of request and have to manually keep track of whether we're still fetching or not. Ideally, there would be way to continuously update cache while fetching (in the queryFn function, for example). That could be achieved by supporting not only promises, but also generators for queryFn.

[phryneas]

Hmm. You could return the initial value as data from queryFn and the running stream as meta and then use the onQueryStarted lifecycle to latch onto the query and process more values.

But as it stands I don't think we're gonna add any official support for other things than start-end.

[artursvonda]

Thanks for the response! I tried that but I couldn't get correct "fetching" status while data is being loaded. And that's my biggest issue with this and something I currently don't know how to achieve – how do I update cache data while fetching, not after request is "done". I would love to utilise tooling around RTK Query and lifecycles like waiting for promise to resolve for query.
I do think this change is compatible with current lifecycles and wouldn't break existing code if implemented since it's opt-in. And I believe it's relatively straight forward change (from API perspective). We already allow async queryFn, why not allow generators as well?

And I don't mean to be too pushy. I'm ok with workarounds. Just haven't found good ones yet.

[markerikson]

I don't think this is something we'd prioritize working on ourselves, but if you have time to play with the idea and submit a PR, we can at least look at it and discuss that further.