Page MenuHomePhabricator

[lib] Handle `[leave/delete]ThreadActionTypes.success` in `reduceThreadActivity`
ClosedPublic

Authored by atul on Oct 6 2023, 11:25 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Nov 19, 5:44 PM
Unknown Object (File)
Wed, Oct 30, 3:35 AM
Unknown Object (File)
Mon, Oct 28, 8:18 PM
Unknown Object (File)
Oct 25 2024, 1:15 AM
Unknown Object (File)
Oct 18 2024, 9:42 PM
Unknown Object (File)
Oct 18 2024, 9:42 PM
Unknown Object (File)
Oct 18 2024, 9:42 PM
Unknown Object (File)
Oct 2 2024, 6:01 AM
Subscribers

Details

Summary

We want to remove entries from ThreadActivityStore once the threads have been removed.

Test Plan

Navigate to thread, log ThreadActivityStore, delete thread, log ThreadActivityStore.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

atul published this revision for review.Oct 6 2023, 11:25 AM
atul added inline comments.
lib/reducers/thread-activity-reducer.js
37–40 ↗(On Diff #31752)

Maybe this check is superfluous and we should just let execution spill into the subsequent for loop?

I guess this prevents state pointing to different object if there are no updates, but there will almost certainly be updates with leaveThreadActionTypes.success and deleteThreadActionTypes.success?

Can remove this if preferred

ashoat added inline comments.
lib/reducers/thread-activity-reducer.js
37–40 ↗(On Diff #31752)

No it's better to keep this. If for instance there is a useSelector(state => state.threadActivityStore) (or a createSelector equivalent), they would be able to "short-circuit" and skip any changes here because you're returning the exact same state object. If you remove it here, that "short-circuit" will be gone

This revision is now accepted and ready to land.Oct 9 2023, 1:59 PM
This revision was landed with ongoing or failed builds.Oct 9 2023, 2:16 PM
This revision was automatically updated to reflect the committed changes.

Shouldn't we also handle processUpdatesActionType action?