the thread info we're passed doesn't have the latest membership status or permissions for the user. this leads to bad user experiences like the leave button not displaying for communities that a user joins through the modal

Okay, in that case:

1. Let's update the component to only take the threadID instead of the whole threadInfo
2. There are several places where you use threadInfo below instead of reduxThreadInfo. It seems like you could use reduxThreadInfo in all cases
3. I suspect that there's a potential risk here that the thread is deauthorized (eg. user leaves the thread on a different client), the thread is removed from Redux, and then this component crashes before it's unmounted by its parent. It's worth investigating if this issue exists, and if it does, we can address in a similar way to ThreadSettings (store the threadInfo in a state, update it when Redux changes but NOT when it disappears from Redux)

I think there's some confusion here. You're suggesting using reduxThreadInfo in the following places:

const communityID = getCommunity(threadInfo);
const resolvedThreadInfo = useResolvedThreadInfo(threadInfo);

we cannot use reduxThreadInfo in either line because it's possible that it's undefined for the given community (user has not joined it yet so it's not in redux). therefore, we have to use threadInfo in both cases. threadInfo comes from the fetchAllCommunityInfosWithNames keyserver call, which returns all thread infos, including ones that the viewer is not a member of

the reason we use reduxThreadInfo at all is, we need the latest membership and permissions info for the thread. if we use threadInfo to determine canLeaveThread (line 75 below), then the leave button will never display. if we use it to determine isMember, then the join button will display for already-joined communities when the user opens the directory (unless we refetch fetchAllCommunityInfosWithNames, which would be expensive)

This should've probably been a code comment, in retrospect. I'll add a comment once this reply is acknowledged.

I think the risk you identified in point 3 is valid, even if we stick with the current approach. I'll do some testing with multiple clients now

Sounds like we should just do what we're doing in ThreadSettings, which I explained above:

(store the threadInfo in a state, update it when Redux changes but NOT when it disappears from Redux)

Can you please review how that file handles things, and update this file to work the same way? Once you grok that, you should be able to:

1. Update the component to only take the threadID instead of the whole threadInfo
2. Update all places where you use threadInfo to instead use a non-nullable reduxThreadInfo
3. Make sure we handle the deauthorization case correctly

1. isn't the new state equivalent to how we use setParams in ThreadSettings? here's the code from ThreadSettings:

React.useEffect(() => {
  if (reduxThreadInfo) {
    setParams({ threadInfo: reduxThreadInfo });
  }
}, [reduxThreadInfo, setParams]);

I've probably misunderstood something...

2. i don't think this is true.

const isMember = useViewerIsMember(threadInfo);
const [joinStatus, setJoinStatus] = useState<
  'joined' | 'notJoined' | 'joining' | 'leaving',
>(`notJoined`);
React.useEffect(() => {
  setJoinStatus(isMember ? 'joined' : 'notJoined');
}, [isMember]);

this hook, and consequently the useEffect, won't re-run if we don't set anything when reduxThreadInfo is falsey

there's been a lot of back and forth on this, so probably best to just pair after lunch today

Never mind, we talked about this and can just leave it as-is