Fix connected sites when logging in

[epeicher]

Related issues

• Fixes STU-944

Proposed Changes

• Adds an event listener to listen for the user-data-updated event.
• Updates the connected sites when the user is logged in.

Testing Instructions

1. Apply this branch and run npm start
2. Select a site with connected sites or connect a few sites
3. Log out
4. Restart the app or press cmd + r if you are in dev mode
5. Log in again
6. Verify that connected sites are displayed

Pre-merge Checklist

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

[Copilot]

Pull Request Overview

This PR fixes an issue where connected sites were not displayed after logging in. The fix adds an event listener that automatically reloads connected sites when user authentication data is updated.

• Adds subscription to user-data-updated event to detect login state changes
• Dispatches loadAllConnectedSites() when a user is logged in

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The subscription is created at module load time but never unsubscribed, which could lead to memory leaks if the module is ever reloaded. While examining similar patterns in new-sites-slice.ts and snapshot-slice.ts, I found they also follow this pattern, which suggests this is an intentional design choice. However, unlike those slices which check additional conditions (e.g., payload.newSites?.length in new-sites-slice), this implementation only checks for currentUserId existence. Consider whether the subscription should fire on every user data update (even when just refreshing the same user's token) or only when the user actually changes from logged out to logged in. If this causes excessive reloading, you may want to track the previous user ID and only dispatch when transitioning from no user to a logged-in user.

Suggested change

	window.ipcListener.subscribe( 'user-data-updated', async ( _, userData ) => {
	const currentUserId = userData.authToken?.id;
	if ( currentUserId ) {
	void store.dispatch( loadAllConnectedSites() );
	}
	// Track the previous user ID to avoid unnecessary reloads
	let previousUserId: string | undefined;
	const unsubscribeUserDataUpdated = window.ipcListener.subscribe( 'user-data-updated', async ( _, userData ) => {
	const currentUserId = userData.authToken?.id;
	// Only dispatch if transitioning from no user to a logged-in user, or if the user ID has changed
	if ( currentUserId && currentUserId !== previousUserId ) {
	void store.dispatch( loadAllConnectedSites() );
	}
	previousUserId = currentUserId;

[github-actions]

📊 Performance Test Results

Comparing 505d826 vs trunk

site-editor

Metric	trunk	505d826	Diff	Change
load	15932.00 ms	11084.00 ms	-4848.00 ms	🟢 -30.4%

site-startup

Metric	trunk	505d826	Diff	Change
siteCreation	24166.00 ms	23284.00 ms	-882.00 ms	🟢 -3.6%
siteStartup	7000.00 ms	7990.00 ms	+990.00 ms	🔴 14.1%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change

[katinthehatsite]

This is so bizarre, I was able to reproduce this on trunk.

The fix worked for me but perhaps we can consider the suggestion from Copilot.

[epeicher]

The fix worked for me but perhaps we can consider the suggestion from Copilot.

Yes, I already considered that, and discarded it because it seemed unnecessary, but I am going to reconsider to avoid excessive reloadings as suggested

[nightnei]

LGTM and I confirm that in trunk we had the issue and it's fixed with the changes 👍

[fredrikekelund]

I think we should take a different approach here.

The user config watcher was implemented to notify the Studio app of changes made by the CLI. The Studio app already has all state in memory, so unless we are truly looking for changes made by another program (the CLI) to the file on disk, resorting to the user config watcher is an indication we need to rethink the state structure, IMO.

The ideal solution here would be to implement src/stores/sync/connected-sites-slice.ts with RTK Query instead (using the createApi API). This would allow us to pass authToken.id as a query dependency and automatically revalidate the data whenever the auth details change. I'll take a stab at this and submit a PR to show what I have in mind.

[epeicher]

I think we should take a different approach here.

The user config watcher was implemented to notify the Studio app of changes made by the CLI. The Studio app already has all state in memory, so unless we are truly looking for changes made by another program (the CLI) to the file on disk, resorting to the user config watcher is an indication we need to rethink the state structure, IMO.

The ideal solution here would be to implement src/stores/sync/connected-sites-slice.ts with RTK Query instead (using the createApi API). This would allow us to pass authToken.id as a query dependency and automatically revalidate the data whenever the auth details change. I'll take a stab at this and submit a PR to show what I have in mind.

Thanks @fredrikekelund for the additional context. The changes followed similar patterns used by other components like new-sites and snapshots, but I didn't realize they had some other reasons for that. Your approach make sense to me, I will review your changes with interest when they’re ready 😄