learningequality / studio

Content curation tools for Kolibri
https://studio.learningequality.org/
MIT License
114 stars 163 forks source link

Client doesn't get updated on syncing of files during channel sync #4028

Open vkWeb opened 1 year ago

vkWeb commented 1 year ago

When channel sync is made using 'Sync resources', we don't create change events for the modifications we make to the database tables. So, the frontend's UI doesn't get updated like for e.g. if a file is deleted from the backend database, the frontend still shows that file in the preview pane.

I discussed this with @bjester and we think that to fix this, we either need to create change events for the modifications we are making or do a re-fetch of all data from the client-side.

@rtibbles sir we need your thoughts on this, what do you think we should do?

vkWeb commented 1 year ago

This issue arose when me and @bjester sir were working on https://github.com/learningequality/studio/pull/4027.

rtibbles commented 1 year ago

The main advantage of doing the change events is that it's targeted onto the specific nodes that have updates - the downside is the 'out of order' changes, where the revision of the change event could in practice be a long way after the sync change, and could stomp another change made by a user in the mean time.

In the particular case with files being removed, that does seem like a case where the change event does seem most useful, because because a fetch will not remove objects that already exist on the indexedDB side, so a change event might be the only way to propagate it?

vkWeb commented 1 year ago

@rtibbles just thinking louder here, I can be completely wrong in what I'm gonna say now.

What if we make 'Sync resources' a blocking operation i.e. frontend will be in loading state until syncing is complete? Backend will do all the processing with change events when the frontend is in loading state and this way we can be sure that we never go out of order with changes?

rtibbles commented 1 year ago

That was the previous solution - in general, I'd rather avoid it, because it tightly couples the asynchronous task processing and the user experience, so users experience more bottlenecks to their workflows.

We do have other cases where after an operation has completed we generate a change event, so this is not so out of the ordinary to do, it's just in the case of syncing it might be quite a larger number of change events.

vkWeb commented 1 year ago

That was the previous solution - in general, I'd rather avoid it, because it tightly couples the asynchronous task processing and the user experience, so users experience more bottlenecks to their workflows.

Totally agreed sir!

We do have other cases where after an operation has completed we generate a change event, so this is not so out of the ordinary to do, it's just in the case of syncing it might be quite a larger number of change events.

Yeah, in this case, if we generate change events for each 'create, delete of resources' we need to just figure out what should we do when a user edits one of the nodes while syncing is in progress...?