Change Details

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 such check on the client left. That check can be addressed in [ENG-4155](https://linear.app/comm/issue/ENG-4155/add-a-admin-role-column-for-threads), at which point we could remove `member.permissions` entirely, which would greatly reduce the size of the `ThreadStore`.

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](https://linear.app/comm/issue/ENG-4155/add-a-admin-role-column-for-threads), at which point we could remove `member.permissions` entirely, which would greatly reduce the size of the `ThreadStore`.

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](https://linear.app/comm/issue/ENG-4155/add-a-admin-role-column-for-threads), at which point we could remove `member.permissions` entirely, which would greatly reduce the size of the `ThreadStore`.