Improve performance of Assistant tab

[fluiddot]

Related to https://github.com/Automattic/studio/pull/549 (this issue was spotted while testing that PR) and https://github.com/Automattic/dotcom-forge/issues/9207.

Proposed Changes

• While testing https://github.com/Automattic/studio/pull/549, I noticed that typing in the Assistant input field caused performance degradation. After debugging the code, I realized that it was caused by a high amount of re-renders of the Assistant tab. The component AuthenticatedView is already memorized to avoid re-renders, but still, I identified the following props to be the culprit of the re-renders:
  • handleSend (in components/content-tab-assistant.tsx)
  • markMessageAsFeedbackReceived (in hooks/use-assistant.ts)
• Memoize handleSend with useCallback.
• Rely on input ref to obtain the value to send in handleSend function, instead of the input state value. Otherwise, the function is re-generated when typing in the input field.
• markMessageAsFeedbackReceived is already memorized but it was being re-generated due to the function sendFeedback from the useSendFeedback hook. This functional has been memorized with useCallback.

Testing Instructions

• Apply the following patch:

  
  diff --git forkSrcPrefix/src/components/content-tab-assistant.tsx forkDstPrefix/src/components/content-tab-assistant.tsx
  index b88c72b761daefb4994af61496e3de9bc3945e95..4789b236e88f4312bd3eca4a258b785d296405f1 100644
  --- forkSrcPrefix/src/components/content-tab-assistant.tsx
  +++ forkDstPrefix/src/components/content-tab-assistant.tsx
  @@ -123,6 +123,7 @@ export const AuthenticatedView = memo(
      handleSend,
      markMessageAsFeedbackReceived,
  }: AuthenticatedViewProps ) => {

• console.log( 'rendering AuthenticatedView' ); const endOfMessagesRef = useRef< HTMLDivElement >( null ); const [ showThinking, setShowThinking ] = useState( false ); const lastMessage = useMemo(

- Run the app with the command `npm start`.
- Open the DevTools.
- Log in to WPCOM with an A8C account.
- Navigate to the Assitant tab.
- Focus on the input field.
- Type some letters.
- Observe that no extra logs are recorded when typing.
- Type quickly several words.
- Observe that the app slows down.
- Submit a request.
- Check the network request made to `wpcom/v2/studio-app/ai-assistant/chat`.
- Observe in the request payload that the `messages` field contains the full prompt.

## Pre-merge Checklist

<!--
Complete applicable items on this checklist **before** merging into trunk. Inapplicable items can be left unchecked.

Both the PR author and reviewer are responsible for ensuring the checklist is completed.
-->

- [x] Have you checked for TypeScript, React or other console errors?

[fluiddot]

I tested this PR and it works, but only for chats that already have messages. Chat, which doesn't have a conversation started, still re-renders.

Should we have a custom comparison function for AuthenticatedView?

Ah, interesting. I'll take a look to figure out how to prevent re-renders in that case. From my testing, this case seems to have less impact on performance as the content being re-rendered is lighter than when having several messages.

While testing this PR, I noticed another issue - entered text is preserved across the sites. I added Automattic/dotcom-forge#9208 for that.

Good catch and thanks for creating the GitHub issue 🙇 !

[fluiddot]

Should we have a custom comparison function for AuthenticatedView?

@wojtekn I've addressed this issue in https://github.com/Automattic/studio/pull/550/commits/8c14f0decaa4dd3f675b1863b62a5dc263fd378c.

[fluiddot]

[...] The only thing I don't think I fully understand is why the AuthenticatedView is rendering twice as soon as I access the Assistant tab with no messages 🤔 Perhaps this is a different issue though:

I checked in React Profile and AuthenticatedView component is only rendered once when navigating to the Assistant tab. I'd like to note that checking re-renders with console logs might not be accurate in some cases.

[katinthehatsite]

I'd like to note that checking re-renders with console logs might not be accurate in some cases.

Interesting, thanks for checking @fluiddot - that sounds like the case I was running into 👍