This differential implements DMActivityHandler component. Its role is the same as ActivityHandler but it works thick threads. I opted for new compoment instead of modifying ActivityHandler since we only need one component for thick threads while there are many ActivityHandlers (one for each keyserver). Therefore I couldn't see an easy way to reuse ActivityHandler.
Details
Details
- Reviewers
tomek kamil inka - Commits
- rCOMM8c1cd8bb2c51: Implement DMActivityHandler
- Create thick thread between users A and B.
- Log in as user A on two devices (on web and on native) and log in as user B on third device.
- Send message from B to A. Open the thread as A on web. Ensure rescinding happens on native.
- Open the thread as A on native. Change opened thread as A on web. Send messages from B to A. Ensure that thread remains read on web.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- marcin/eng-8944
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/handlers/dm-activity-handler.js | ||
|---|---|---|
| 4–5 ↗ | (On Diff #43896) | Can be merged. |
| lib/handlers/dm-activity-handler.js | ||
|---|---|---|
| 92–95 ↗ | (On Diff #44000) | What's the point of this? Does processAndSendDMOperation already dispatch actions? Given you're returning empty collections on line 46, it seems like no reducers will have any changes as a result of these actions... so probably best to remove these lines. @marcin, if this makes sense to you, can you remove these lines as part of the same stack as D13260, and land the fixes together? |
| native/components/dm-activity-handler.react.js | ||
| 1 ↗ | (On Diff #44000) | Nit: we always have an extra newline after this |
| 12–21 ↗ | (On Diff #44000) | Looks like most of this was copy-pasted from native/socket.react.js. Could you factor it out in a follow-up diff? |
| web/components/dm-activity-handler.react.js | ||
| 1 ↗ | (On Diff #44000) | Same here |
| lib/handlers/dm-activity-handler.js | ||
|---|---|---|
| 92–95 ↗ | (On Diff #44000) | I figured that we might want to task status of this action. This is the approach that we are already using in, for example, useChangeThreadSettings. If we are running for thick threads we return empty collections so that we can call it from dispatchActionPromise and track its status. |
| lib/handlers/dm-activity-handler.js | ||
|---|---|---|
| 92–95 ↗ | (On Diff #44000) | Unless we have a reason for it (such as tracking loadingStatus), I think we should remove the dispatch
Do we track the status of updateActivityActionTypes? |