[Task] Room preview should try to update the local data

[ganfra]

Currently, using the room preview api for room we already know, like those with invited or knocked states, is waiting for the server to return, because we want to ensure the data is accurate.
Could be nice to return the local data right away, but still try to fetch data from server, and save this updated data in the store.

[bnjbvr]

It's a nice idea, but how would that work?

• The caller knows the information may be outdated, and may call again later?
• The caller provides a callback that's called when the server response has been received?
• or something else you had in mind?

[mxandreas]

It's a nice idea, but how would that work?

My understanding was that we refresh the data anyway when the preview is opened. We just would not block opening the preview because of that. Just my 2c.

[jmartinesp]

I see 2 ways we could try to have this behaviour:

1. With the latest changes in the timeline APIs it should be possible now to get a room without a timeline, so we could use the new Client::get_room to get the current local data for those known rooms and then using RoomPreview to get the updated data. This has some problems though for Android: our current code assumes a Room will always have a timeline and we have designed several APIs like this, so it would require a not that small refactor to work (this refactor would be required sometimes soon anyway). Besides, we'd have to load data from 2 different sources, and abstract those at the app level.
2. Modifying the RoomPreview code (yes, again 😓) to either create 2 separate public methods to get a RoomPreview with whatever synced data we have and another one for loading remote data, or have a single method returning something like Result<(Option<RoomPreview>, RoomPreviewCallback)>, with the first item in the tuple being the local data in a RoomPreview format, if we have it, and the second one being some Rust trait that would act as a listener and would receive the remote data.

EDIT: actually, I just realised this is what Benji proposed above, only a bit more detailed 😅 .

[bnjbvr]

Result<(Option, RoomPreviewCallback)>

I was imagining some method like the one described in option (2) yeah; the return type you described would be at the FFI layer. At the SDK layer, this could return Result<Option<RoomPreview>, tokio::sync::oneshot::Receiver<RoomPreview>> or something like that.