There's also no benefit to memoizing a string (unless there was some intense computation required to determine the string). The benefits of memoization come into play with objects (including arrays, functions, etc) and maintaining referential equality.

Found the following resource extremely helpful, might be worth a read: https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/

Can we just make this check activeStep === 'members'?

We're pulling parentThreadInfo out of props on line 38, can we pull out onClose there as well?

Do we not want to include the user.id !== currentUserId check from above here as well?

Should this be plural or just Visibility?

Typically we define the Props type for a component right before the component is defined. Eg in this case we'll probably want to move Props to around line 49.

Why are we using .trim() here? It seems like it could break some equality assumptions to modify channelName like that?

We usually don't leave TODO comments in the codebase.

I think you also have an extra slash at the start of the comment (/// vs //)

Elsewhere in the codebase we have a newline after the // @flow annotation

You refer to the same type as VisibilityType in compose-subchannel-modal.react, would be good to match that for consistency

I believe we can use the megaphone icon in the CommIcons component here instead

I had to use void type, because onClose props in Modal component requires it. Otherwise, flow throws this error:

Cannot create `Modal` element because  mixed [1] is incompatible with  undefined [2] in the return value of property `onClose`

Sure, I check that and it could be $ReadOnlySet. I set this temporary and I missed it. I will change that

I prepared this function at the beginning of working on this component. At that moment I used it for changing channel type in two another functions, but finally I use another approach.

So, we can move it inside onChangeChannelName

I tried to keep conventions like in AddMembersList component, but I could change it.

This object contains props that are provided to Stepper component (D5186) action buttons.
I gathered it in one place to avoid using useCallback in useMemo and to have navigation of modal in one place.

I tried to remove unnecessary whitespaces in channelName, because it could allow us to create a channel with whitespaces-only name.
Alternatively, we could trim it when submitting the form.

What equality assumptions do you mean?

Sure, I left this comment here as an interface. This function is already implemented in the next diff.

This is tested value, that allow us to avoid resizing of the whole modal. We could also use better solution, using text-overflow: ellipsis;, but this approach might require a separate diff/task with Modal modifications.

Members from parentThreadInfo are also community members, but we could also use parenThreadInfo.members inside parentMembersList instead of communityMembers.
Logic works fine, but I can code it better.

currentUserId is currently included in parentMembers set. For better code maintenance, I could include this line.

Sure, this approach requires modifications in AddMemberGroup css. For now, I could remove it and create separate diff for that.

I tried to fix some flow type problems with that, but I check it now and it seems to work correctly without this workaround.

I put a reply in the previous update, but it seems that it disappeared.

Using position: sticky here allow us to keep searchbar always on the top of the modal. Other solutions could require some changes in structure of the component. I tried to avoid nesting a scrollable component in another scrollable component, thus using sticky here seems to be the simplest solution.

Here is a sample video that show the benefits of using it here:

So, I guess using sticky here is benefitable.

This is addressed in the next diff in the stack D5211