Page MenuHomePhabricator

[lib] Update `messageStore.messages` with `msgStoreOps` for [logOut/deleteAcc/leaveThr/etc].success actions
ClosedPublic

Authored by atul on Jun 2 2022, 5:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 9, 11:41 AM
Unknown Object (File)
Sat, Nov 9, 11:41 AM
Unknown Object (File)
Sat, Nov 9, 11:41 AM
Unknown Object (File)
Fri, Nov 8, 8:08 AM
Unknown Object (File)
Wed, Nov 6, 10:16 PM
Unknown Object (File)
Tue, Nov 5, 2:02 AM
Unknown Object (File)
Wed, Oct 23, 4:19 PM
Unknown Object (File)
Wed, Oct 23, 4:18 PM

Details

Summary

Instead of getting messageStore.messages from the filteredMessageStore returned by updateMessageStoreWithLatestThreadInfos(...)... we use the messageStoreOps returned by updateMessageStoreWithLatestThreadInfos(...) to compute the new message store.

Note that a messageStore.messages is still being created within updateMessageStoreWithLatestThreadInfos(...) and will be removed in a subsequent diff


Depends on D4201

Test Plan

This should be a straightforward refactor given we've had assertMessageStoreMessagesAreEqual in place for some time now.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

atul requested review of this revision.Jun 2 2022, 5:28 PM
tomek requested changes to this revision.Jun 3 2022, 4:29 AM
tomek added inline comments.
lib/reducers/message-reducer.js
856–859 ↗(On Diff #13317)

Is there a reason why we can't use processedMessageStore?

This revision now requires changes to proceed.Jun 3 2022, 4:29 AM
atul requested review of this revision.Jun 17 2022, 1:32 PM
atul added inline comments.
lib/reducers/message-reducer.js
856–859 ↗(On Diff #13317)

Yeah, because right now the "ops" only modify messageStore.messages... we need to modify the other properties of messageStore (eg threads, local, etc) "the old way"

tomek added inline comments.
lib/reducers/message-reducer.js
856–859 ↗(On Diff #13317)

Ok, that makes sense. But what do you think about using filteredMessageStore as an argument of processMessageStoreOperations? By doing that it should be ok to just use the result of processMessageStoreOperations - it will be more maintainable

const processedMessageStore = processMessageStoreOperations(
  filteredMessageStore,
  messageStoreOperations,
);

return {
  messageStoreOperations,
  messageStore: processedMessageStore,
This revision is now accepted and ready to land.Jun 20 2022, 2:44 AM

Ok, that makes sense. But what do you think about using filteredMessageStore as an argument of processMessageStoreOperations? By doing that it should be ok to just use the result of processMessageStoreOperations - it will be more maintainable

const processedMessageStore = processMessageStoreOperations(
  filteredMessageStore,
  messageStoreOperations,
);

return {
  messageStoreOperations,
  messageStore: processedMessageStore,

That definitely makes sense, but we can't do it just yet: https://phab.comm.dev/D4201?vs=on&id=13644#121744. It'll take some more refactoring, but that's definitely the goal. These initial diffs are mostly about removing usages of assertMessageStoreMessagesAreEqual(...) so it can be removed altogether.

rebase after cherrypicking and before addressing feedback

Slight feedback to @atul – I think if you find yourself doing a refactor where you do "the same thing" over and over in different places, it can actually be easier to review if you just put it all into one slightly larger diff

Slight feedback to @atul – I think if you find yourself doing a refactor where you do "the same thing" over and over in different places, it can actually be easier to review if you just put it all into one slightly larger diff

Yeah I agree, doing it like this was was tedious for me + reviewers. Have a diff locally where I just do this for all remaining actions in one go.