element-hq / element-hq/element-web
TAC indicator can be slow to display activity
- Dominant language
- TypeScript
- Stars
- 13.5k
- Forks
- 2.8k
- PR merge metrics
- PR metrics pending
Description
### Steps to reproduce
Untested, but along the lines of:
1. Have a client with the TAC enabled, no notifications and no activity, except for one thread which has activity.
2. Load that client
### Outcome
#### What did you expect?
TAC indicator gets a black dot as soon as the client starts to show activity in that thread.
#### What happened instead?
Dot appears 30 seconds after the client is loaded (when a sync happens and useUnreadThreadRooms re-checks).
It's kind of a hack that useUnreadThreadRooms just re-checks on sync as it will inherently miss any messages that arrive in pagination requests, which is what's happening here (the thread gets loaded when we updateThreadMetadata after load).
This is a symptom of us not storing our history in the client and the server not telling us about unread messages (ie. activity) but the client expecting to be able to display which rooms/threads have activity. We could add a listener for when the client paginates but the state will still be wrong if it doesn't happen to paginate. Plus, we would not want to do this calculation frequently as it's quite expensive, so running it on every new event would melt the client.
We could introduce a hierarchy tracking unread states over threads/rooms/spaces etc that only updates when necessary, but again, the state would still be wrong for threads or chunks of timeline we simply haven't loaded yet.
### Operating system
_No response_
### Application version
_No response_
### How did you install the app?
_No response_
### Homeserver
_No response_
### Will you send logs?
No
Contributor guide
Assessment
This issue has not been assessed yet.