Add context for sync sites

[sejas]

• Closes https://github.com/Automattic/dotcom-forge/issues/9573

Proposed Changes

• Add context and move existing management sync hook inside it.
• Improves the performance avoiding to read the appData file each time we change the tab to Sync.
• Adapt tests

Testing Instructions

Apply this diff to better highlight the loading time for reading connected sites.

diff --git a/src/ipc-handlers.ts b/src/ipc-handlers.ts
index 475767c..3b92108 100644
--- a/src/ipc-handlers.ts
+++ b/src/ipc-handlers.ts
@@ -280,6 +280,10 @@ export async function disconnectWpcomSite(
 	return updatedConnections.filter( ( conn ) => conn.localSiteId === localSiteId );
 }
 
+function sleep( ms: number ) {
+	return new Promise( ( resolve ) => setTimeout( resolve, ms ) );
+}
+
 export async function getConnectedWpcomSites(
 	event: IpcMainInvokeEvent,
 	localSiteId: string
@@ -287,6 +291,7 @@ export async function getConnectedWpcomSites(
 	const userData = await loadUserData();
 	const currentUserId = userData.authToken?.id;
 
+	await sleep( 3000 );
 	if ( ! currentUserId ) {
 		return [];
 	}

• Run STUDIO_SITE_SYNC=true npm start
• Click on the Sync tab.
• Connect a site.
• Switch between tabs.
• Return to the Sync tab.
• Confirm that the connected sites are still displayed.
• Before this PR, the initial screen briefly appeared before the connected sites finished loading.

Pre-merge Checklist

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

[katinthehatsite]

The functionality works for me as expected. I reviewed the code and it looks good. One thing that I am wondering is whether we should break sync-sites-context into a couple of different files so that its responsibilities are limited to providing state and context for the connected sites and sync states.

For instance, we could move the use-site-sync-management and the hook for pulling operation into two different files and then pass through the context? My concern is that if we also add the push operation to this, that file will be hard to manage and navigate.

[sejas]

For instance, we could move the use-site-sync-management and the hook for pulling operation into two different files and then pass through the context? My concern is that if we also add the push operation to this, that file will be hard to manage and navigate.

@katinthehatsite , great observation. I've refactored the code to be every main hook in a separate file. I've grouped them inside the same folder to indicate they belong to a given context. I also moved the state to the context so that way we reduce the risk of small hooks being used directly from the components.

Let me know what you think. Thank you!

[katinthehatsite]

Thanks for making the changes, I think the code is much more readable right now 😍

[wojtekn]

@sejas when I use a timeout snippet, and I open a site that has connected sites, and then switch to another site, I see connected site from the previous site for a while. It works well without the snippet, though.

[sejas]

@sejas when I use a timeout snippet, and I open a site that has connected sites, and then switch to another site, I see connected site from the previous site for a while. It works well without the snippet, though.

Thanks for testing it, and finding that "glitch" when changing sites.
I think that's fine. This PR wanted to improve the performance when changing tabs, so the sync tab component unmounts and mounts.
Switching sites will have the same performance as trunk.
The timeout just exaggerates what is happening. I don't think we need to optimize it further. Let's keep an eye on that flow.