This line will be changed when I will be refactoring TypeaheadTooltip on web.

Why are you importing them just to pass them down? Will any other function ever be passed to typeaheadButtonRenderer and typeaheadTooltipActionsGetter?

Why isn't this a component?

Right now no other function will be ever passed, because we only use typeahead tooltip for mentioning.

Nit, can be simplified

Should be SuggestionItemType to maintain naming convention.

1. Maintaining web convention: see this.
2. FlatList renderItem requires an function and not a component, so just to match function signature.

I think that this part should be changed so I see two potential solutions:

1. Convert this function to component -> it would be rendered where typeaheadButtonRenderer is called in typeahead tooltip component. I personally don't like this solution.
2. Move renderTypeaheadButton function from typeahead tooltip component outside: we would pass a renderer function as we do right now, but <Button> part would be moved to this rendered function too.

I believe that first option should be applied.

Nit: shorthand

This condition should be reversed to reduce indentation

Yes, see D8909.

I don't think it's necessary since TypeaheadSuggestionItem will be renamed to MentionTypeaheadSuggestionItem here: D8898 and in the future TypeaheadSuggestionItem might be a little bit different.

Yes, it might be an performance issue, but if you look closely, every time we enter a new character, getNewTextAndSelection and focusAndUpdateTextAndSelection in execute (in mentionTypeaheadTooltipActions) are going to be "recalculated" since we pass textPrefix (or query) parameter, which is obviously being changed every time we type sth in input bar, thus all memoized components would be recalculated again. We could move execute to the typeahead button component and achieve O(n) time complexity rather than O(2n) but I don't think it would bring a significant improvement. Also look at previous code. useCallback was also executed every time user has entered a character (see usernamePrefix). We probably should refactor getNewTextAndSelection and focusAndUpdateTextAndSelection to avoid passing query every time user inputs a new character in the future.

I agree, but I will introduce new else-if for suggestion.type === 'chat'. I could handle one case earlier and reduce indentation for the second case, but I personally don't think it will be more readable.

I haven't looked too closely here, and I trust @tomek and @patryk can figure this out. But two quick notes I'd like to share:

1. If we are reducing the number of renders by 2x, that is definitely worthwhile. On the other hand, if it's just improving the performance of a simple algorithm, it's not as important.
2. We should ask ourselves if it's really necessary to rerender every single TypeaheadTooltipActionItem<TypeaheadSuggestionItem>. Is there something there that justifies a rerender – in other words, does it look different after? If not, then we should search for a way to avoid the rerender.