native: quick-n-dirty app badge management #4220
Conversation
packages/shared/src/store/dbHooks.ts
Outdated
| @@ -200,7 +200,7 @@ export const useContacts = () => { | |||
|
|
|||
| export const useUnreadsCount = () => { | |||
| return useQuery({ | |||
| queryKey: ['unreadsCount'], | |||
| queryKey: ['unreadsCount', useKeyFromQueryDeps(db.getUnreadsCount)], | |||
There was a problem hiding this comment.
this works but causes a lot of seemingly irrelevant query updates – would love to know if there's a way to reduce
There was a problem hiding this comment.
Ya, I mean this is true in a number of places, mostly because our query invalidation is very coarse. I think fine for now + we should address at a higher level in a perf pass sometime.
davidisaaclee
requested review from
dnbrwstr,
patosullivan and
latter-bolden
packages/app/lib/notifications.ts
Outdated
|
|
||
| // `useUnreadsCount` updates with a lot of false positives - debounce so we | ||
| // don't run the updater too frequently | ||
| const debouncedQueryKey = useDebouncedValue(query.dataUpdatedAt, 500); |
There was a problem hiding this comment.
Since the query.data is just number | undefined, why not use that number as the key?
There was a problem hiding this comment.
I was thinking about this case: This query's data could remain the same but badge could need a change if there is an equal number of +/- read/unreads in different rooms in one transaction, causing no change in the total unread count. (If that's the case, wouldn't the badge also reflect no change in value? Not necessarily, because the badge only represents non-muted channels - I thought useUnreadsCount contains muted channels.)
afk rn - I'll leave a comment inline if that makes sense
There was a problem hiding this comment.
You're right that it does -- fwiw useUnreadsCount does not appeared to be use anywhere else besides here, so feel free to modify if helpful.
|
@dnbrwstr I changed I tried using the value of that query for the badge count instead of counting the presented notifications, but it looks like that query counts the number of unread channels, not unread messages (and it doesn't seem trivial to change that). Going to merge, happy to do a follow-up if you find issue with the recent changes |
Fixes TLON-3149
Fixes TLON-3241
Both of these features will be faster (i.e. no perceptible delay between action/receipt and UI update), simpler to maintain, and more flexible when implemented on backend (as mentioned in tickets), but here's a quick fix.
There's some latency between opening a channel and the notifications going away – I think this is latency from marking stuff as read and getting the db update. Going in and out of the channel quickly still gets the notifications cleared – I think...
We update the badge in two places:
number of currently-presented notifications+ 1. I think this can drift into the wrong count when receiving notifications in quick succession, but should always at least show some badge if you have an unread; and will be corrected by...