In D8593#254333, @atul wrote:

Can't we just pass in threadID as a prop to CommunityRolesModal and pull the threadInfo from Redux directly? It seems weird to handle this updating manually when the whole point of React is that it handles updates to state? We should first figure out why the threadInfo being passed into CommunityRolesModal isn't changing + triggering a re-render

Yeah, I think that is definitely the better move + makes the whole threadInfo logic way simpler and conventional.

As for why the threadInfo isn't changing, I think it might have to do with perhaps how CommunityRolesModal remains open while the role is created. I'm not certain, but I will update this diff to pull the threadInfo directly from Redux to not block it, and meanwhile investigate locally

In D8593#255118, @ashoat wrote:

The point of this code:

React.useEffect(() => {
  if (reduxThreadInfo) {
    setUpdatedThreadInfo(reduxThreadInfo);
  }
}, [reduxThreadInfo]);

Is to make sure that the threadInfo we're using is always set, EVEN IF the thread is deauthorized. It protects against an error case where somebody is editing a community's roles, and gets deauthorized from that community in that moment. As currently written, that case would crash the entire app, as it would result in an undefined threadInfo being passed to useRoleMemberCountsForCommunity.

In the future, @rohan it's your responsibility to understand the change you're making, and to explain it to @atul (with references to eg. ThreadSettings) if he doesn't immediately understand why you're doing it. If I recall correctly, I explicitly requested that you write it this way, and explained in the moment why it should be written this way.

This sort of situation is frankly deeply concerning to me... it's another case (following this one) where my review appears to "required". We need to get to a place where the rest of the team is able to put code out (and review code) without needing me to step in. Ultimately, it's on the diff author to understand the changes they're making, and to explain them thoroughly / thoughtfully.

Sorry for the misunderstanding, I thought it was for a different reason (ensuring that on native, since the React Navigation props for ThreadInfo doesn't update when navigating back from the create roles screen to the community roles screen, so the solution to that was to pull in the latest ThreadInfo (if it exists) from redux.

Here on web, if there's a situation where say a user who has permissions to create/edit roles is in the process of editing a role, and someone changes their role, I didn't experience any crashes when testing before making the change. Instead, all that happened was the expected error message occurred where it displayed that there was an unknown error, please try again (since they no longer had role change permissions).

I'm probably missing the method you're talking about to re-create the crash, and if so it makes sense that we should definitely avoid that. If that is the case, I can bring back the original method of pulling from Redux if it exists