Page MenuHomePhabricator

[lib] Simplify threadIsGroupChat check
ClosedPublic

Authored by ashoat on Sep 29 2023, 11:49 AM.
Tags
None
Referenced Files
F3403558: D9332.diff
Tue, Dec 3, 3:49 AM
F3400580: D9332.id31577.diff
Mon, Dec 2, 7:54 AM
F3399989: D9332.diff
Mon, Dec 2, 5:45 AM
Unknown Object (File)
Sun, Dec 1, 3:15 AM
Unknown Object (File)
Fri, Nov 29, 7:14 PM
Unknown Object (File)
Fri, Nov 15, 8:53 AM
Unknown Object (File)
Thu, Nov 7, 10:37 PM
Unknown Object (File)
Thu, Nov 7, 10:37 PM
Subscribers

Details

Summary

We can simplify this check because of two properties:

  1. I grep'd around and confirmed that despite supporting RawThreadInfo | ThreadInfo, threadIsGroupChat is only ever called with a ThreadInfo parameter. This is confirmed by Flow.
  2. In D8072, @rohan updated getRelativeMemberInfos to filter out anybody with a "falsey" role from a ThreadInfo. RawThreadInfo will still have these members, but since threadInfoFromRawThreadInfo calls getRelativeMemberInfos to determine its members property, that means that a ThreadInfo will NEVER have a member with a falsey role.

Given these two observations, I've made three changes:

  1. Restricted the function parameter to only take a ThreadInfo.
  2. Remove the call to threadMembersWithoutAddedAshoat. This function never removes members unless they have a falsey role, so it is a no-op in this case.
  3. Remove the filter. Similar to above, this filter never removed members unless they had a falsey role.

By removing the member.permissions check, we now have only one such check on the client left. That check can be addressed in ENG-4155, at which point we could remove member.permissions entirely, which would greatly reduce the size of the ThreadStore.

Test Plan

Careful reading and Flow

Diff Detail

Repository
rCOMM Comm
Branch
ashoat/group-chat
Lint
No Lint Coverage
Unit
No Test Coverage