Store more Assistant state in ChatContext to uncouple it from component tree

[fredrikekelund]

Related issues

• Fixes https://github.com/Automattic/dotcom-forge/issues/9575
• Builds upon my changes in Merge ChatInputContext with ChatContext #786

Proposed Changes

If a user switches tabs in Studio while waiting for a response from Assistant, the response is never registered. This happens because the relevant state is stored at the bottom of the component tree—not in a context provider (and the component tree happens to be configured in a way where the state resets when users switch tabs).

This PR moves several pieces of state from the useAssistant and useAssistantApi hooks to ChatContext to mitigate this problem.

Testing Instructions

1. Go to the Assistant tab
2. Submit a message that takes a while longer to process
3. Quickly go to a different tab
4. Quickly go back to the Assistant tab
5. Ensure that the loading state is still visible and that the response shows up as expected
6. Repeat the process for a different site and navigate between the sites while responses are loading
7. Do some additional smoke testing for the Assistant to ensure it works as expected

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[bcotrim]

Code LGTM and works as described 👍

One minor note:
When switching tabs, to a previous conversation, there's a scrolling behavior that I don't think it happened before.
I believe it was a side effect from us moving the state.

Screen.Recording.2025-01-10.at.18.57.26.mov

[fredrikekelund]

Nice catch, @bcotrim 👍

That turned out to be a surprisingly tricky issue to debug. Apparently, React's StrictMode intentionally runs effect hooks twice when components are initialized as a way of surfacing bugs in the application. In our case with a hook that scrolls the viewport, their reasoning doesn't really apply, and I recommend that we accept that the dev and prod environments behave differently.

We could also drop StrictMode entirely, or implement some kind of local workaround. However, neither of those approaches seems fitting to me.

[fredrikekelund]

I added a key prop specifically for ContentTabAssistant in src/components/site-content-tabs.tsx instead.

[bcotrim]

That turned out to be a surprisingly tricky issue to debug. Apparently, React's StrictMode intentionally runs effect hooks twice when components are initialized as a way of surfacing bugs in the application. In our case with a hook that scrolls the viewport, their reasoning doesn't really apply, and I recommend that we accept that the dev and prod environments behave differently.

Thank you for the detailed explanation—TIL! I agree that the best approach is to accept this behavior in development for now. My only suggestion would be to add this information as a code comment to save future us (or another developer) some research time.

[fredrikekelund]

My only suggestion would be to add this information as a code comment to save future us (or another developer) some research time

Makes sense 👍 I've added an explanation and a link to this PR

[wojtekn]

Works as expected.