This differential updates badge count on web and desktop according to the same semantics as the parent differential does on native.
Details
Details
- Apply this patch: https://gist.github.com/marcinwasowicz/2e56c2d67cd69b1ef279bc748ff1fb61
- Send messages from web client to desktop/web client.
- Ensure badge count stayes consistent and takes into account new thick threads.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- marcin/eng-8243
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/selectors/thread-selectors.js | ||
|---|---|---|
| 261 ↗ | (On Diff #43814) | This is no longer allUnreadCounts - it never was, but now we should probably name it e.g. thinThreadsUnreadCounts? |
| web/app.react.js | ||
| 562 ↗ | (On Diff #43814) | Why do we change it from a hook to a component? |
| web/push-notif/badge-handler.react.js | ||
| 24 ↗ | (On Diff #43814) | Maybe rename it to thinThreadsUnreadCount? |
| web/push-notif/notif-crypto-utils.js | ||
| 604 ↗ | (On Diff #43814) | Is it really guaranteed that the notif has a threadID? Are we sure we want to have this invariant? |
| 1346 ↗ | (On Diff #43814) | What is it for? |
| web/app.react.js | ||
|---|---|---|
| 562 ↗ | (On Diff #43814) | It hadn't worked if I just would have moved useBadgeHandler() here. Therefore I figured I had to refactor it into a component. The reason for moving it here is that now BadgeHandler is dependent on Tunnelbroker so it must be rendered after TunnelbrokerProvider is rendered. |
| web/push-notif/notif-crypto-utils.js | ||
| 604 ↗ | (On Diff #43814) | It is guaranteed by flow types. If we are executing in this branch it means that we are processing thick thread notification. All thick thread notification types have obligatory threadID property. Therefore executing in this branch for notification that doesn't have threadID is a bug that we should be alarmed about. |
| 1346 ↗ | (On Diff #43814) | This is extensively used in this file. localforage method to set multiple items at once sets new synchronization value after successful write. The role of this value is explained in detail in this comment: https://linear.app/comm/issue/ENG-8574/handle-the-race-condition-between-the-main-app-and-the-notification#comment-584caf12. The only difference is that the value is a string and instead of incrementing we just create brand new one. |