Page MenuHomePhabricator

[lib] generate message store ops for threads after sending message
ClosedPublic

Authored by kamil on Apr 13 2023, 7:33 AM.
Tags
None
Referenced Files
F3507354: D7418.id25107.diff
Fri, Dec 20, 8:28 PM
F3507191: D7418.id25352.diff
Fri, Dec 20, 7:37 PM
Unknown Object (File)
Wed, Dec 18, 10:11 PM
Unknown Object (File)
Wed, Dec 18, 7:59 PM
Unknown Object (File)
Thu, Dec 5, 1:30 AM
Unknown Object (File)
Thu, Dec 5, 1:30 AM
Unknown Object (File)
Nov 5 2024, 4:21 AM
Unknown Object (File)
Nov 5 2024, 4:20 AM
Subscribers

Details

Summary

This code generates operations needed for updating threads part of message store after message was sent with success.

Depends on D7417

Test Plan

Try to send message (with success) using different flows on both web and native

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil held this revision as a draft.
kamil published this revision for review.Apr 13 2023, 8:28 AM
tomek added inline comments.
lib/reducers/message-reducer.js
1248
1256

Does it make sense to spread it here?

1267–1270

Shouldn't we use processedMessageStore.threads or something?

This revision is now accepted and ready to land.Apr 17 2023, 5:36 AM

remove spread operator and rebase

lib/reducers/message-reducer.js
1248

I don't think that's a good change, single thread is what's defined by threadID key, this object:

{
        ...messageStore.threads[threadID],
        messageIDs: newMessageIDs,
},

This right here is the threads object (but I agree it will have one key).
With this change later I will have to use: payload: { threads: updatedThread }, which I think is more confusing.

1256

looks like not - thanks for pointing

1267–1270