Implement RTK Query approach for fetching wpcom sites #2132

epeicher · 2025-11-25T19:29:19Z

Related issues

Related STU-1035
Related STU-710

Before

CleanShot.2025-11-26.at.20.17.26-trimmed.mp4

After

CleanShot.2025-11-26.at.20.18.33.mp4

Proposed Changes

Migrated from custom useFetchWpComSites hook to RTK Query with useGetWpComSitesQuery. The new query uses the userId to invalidate the cache
Improved state management with automatic caching, background refetching, and request deduplication
Reorganized sync utilities:
- Moved sync-related utilities from src/hooks/use-fetch-wpcom-sites/ to src/modules/sync/lib/
- Consolidated types into src/modules/sync/types.ts
- Created shared sync-support.ts module for getSyncSupport and helper functions
Updated all imports across 20+ files to reflect new structure
Removed deprecated hook directory
Enables by default the Streamline Onboarding feature flag

Testing Instructions

Apply this branch and run npm start
Use or create a site that does not have any connected sites
Click on Publish site button and observe that the loading experience is fine (there are no multiple loading indicators)
On the Sync tab, click on Publish site and check that the loading is minimal as the sites are cached
Test also the Pull site button
Delete or create a new site on WordPress.com
Click on the Publish site button, check that the deleted or created site is displayed (there could be a delay)
Log out and log in with a user with no sites
Click on the Publish site button
Check that the Find a perfect plan modal is displayed
Check different use cases and confirm that the sites are correctly loaded

Pre-merge Checklist

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

github-actions · 2025-11-26T20:26:09Z

📊 Performance Test Results

Comparing 6ba4ba7 vs trunk

site-editor

Metric	trunk	`6ba4ba7`	Diff	Change
load	12705.00 ms	13875.00 ms	+1170.00 ms	🔴 9.2%

site-startup

Metric	trunk	`6ba4ba7`	Diff	Change
siteCreation	19489.00 ms	22874.00 ms	+3385.00 ms	🔴 17.4%
siteStartup	8005.00 ms	10068.00 ms	+2063.00 ms	🔴 25.8%

Results are median values from multiple test runs.

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

sejas

Great work! Thanks for moving the wpcom sites request to RTK. Now it doesn't block the user every time we click on the buttons.
I just noticed that we display a loading state in the push site button every time we change tabs.

loading-push-site-button.mp4

sejas · 2025-11-26T23:15:28Z

src/modules/sync/index.tsx

-			dispatch( connectedSitesActions.openModal( pendingModalMode ) );
-			setPendingModalMode( null );
+		if ( isModalOpen && isAuthenticated && ! isUninitializedSyncSites ) {
+			refetchWpComSites().catch( ( error ) => {


Would be possible to refetch wpcom sites inside openModal action or call it at the same time?

Absolutely, I have done the changes on d7113b1, I think that is better.

I have also fixed the loading indicator in the button as part of 9a6f74f

…a-for-users-without-sites-displays-before-sites-are-loaded

epeicher · 2025-11-27T18:07:08Z

common/lib/cache-function-ttl.ts


 function pruneCache(): void {
-	for ( const [ fn, cachedResults ] of cache ) {
+	for ( const [ _, cachedResults ] of cache ) {


This is a lint fix, unrelated to this PR

sejas

@epeicher, thanks for making the adjustments. The PR looks good. I only found that Studio throws a warning when clicking Publish site from a different tab, like overview.

Failed to refetch sites: Error: Cannot refetch a query that has not been started yet.

sejas · 2025-11-28T09:44:38Z

src/stores/sync/wpcom-sites.ts

+// Schema for WordPress.com sites endpoint
+const sitesEndpointSiteSchema = z.object( {
+	ID: z.number(),
+	is_wpcom_atomic: z.boolean(),


We have parts of this type duplicated in sync-support.ts. Can we unify them?

studio/src/modules/sync/lib/sync-support.ts

Lines 3 to 8 in b09206b

// Schema type for WordPress.com sites endpoint

export type SitesEndpointSite = {

ID: number;

is_wpcom_atomic: boolean;

name: string;

URL: string;

Definitely, this type can be inferred from the schema, I will update this

Done as part of 427d3ab, duplication removed, great catch!

sejas · 2025-11-28T09:59:38Z

src/modules/sync/index.tsx

+		try {
+			const result = await refetchWpComSites();
+			return result.data ?? [];
+		} catch ( error ) {
+			// Query might not be ready to refetch yet (e.g., was skipped due to offline)
+			console.warn( 'Failed to refetch sites:', error );
+			return [];
+		}


I see this pattern of catching the refetchWpComSite error repeated a few times. I wonder if makes sense to move the try catch inside the query and always return an empty array if it fails.

Yes, that's right, the refetchWpComSite is not always ready, so it can throw errors, I will encapsulate this on a function 👍

This has been simplified as part of 63cc6b8, as the effect is not required anymore after refetching the sites directly. There are not any errors now, but I have added the void operator to refetch the sites on the background (i.e. do not use await every time) and ignore any potential errors during the refetch, please let me know if you think it would be better to handle and maybe log them.

Additionally, I have consolidated both buttons into one with a condition that redirects to the Sync tab only when required in the commit 7e1bbdb

…a-for-users-without-sites-displays-before-sites-are-loaded

katinthehatsite

First, nice work 👍 This is a huge PR and lots of work so well done!

I noticed one thing that when the sync modal is already open, I see the loading state on the Publish site button in the background:

I also see it for the case when I click on the Publish site in the top right corner and then close the modal, the loading state persists in that case instead of going away.

katinthehatsite · 2025-12-01T10:04:17Z

src/components/publish-site-button.tsx

+			setSelectedTab( 'sync' );
+		}
+		if ( isAuthenticated && ! isUninitializedSyncSites ) {
+			// Refetch sites on the background but ignore errors


Suggested change

// Refetch sites on the background but ignore errors

// Refetch sites in the background but ignore errors

The query is executed in the background so it is not required to indicate that in the button

epeicher · 2025-12-01T18:05:21Z

Thanks for the review @katinthehatsite!

I noticed one thing that when the sync modal is already open, I see the loading state on the Publish site button in the background

Yes, that was expected as I included isBusy for the button while the sites are being fetched in the background, but I understand that seems confusing so I have removed it as part of b134968

fredrikekelund

Great refactoring, I love to see it 👍

I left a couple of comments, mostly with a focus on how we can make the code more declarative and rely on RTK Query internals more, or move logic from components inside mutations.

I haven't tested extensively yet, but happy to do so in a second review later.

fredrikekelund · 2025-12-02T11:17:53Z

src/components/publish-site-button.tsx

+	const handlePublishClick = useCallback( () => {
+		if ( redirectToSync ) {
+			setSelectedTab( 'sync' );
+		}
+		if ( isAuthenticated && ! isUninitializedSyncSites ) {
+			// Refetch sites in the background but ignore errors
+			void refetchWpComSites();
+		}
 		dispatch( connectedSitesActions.openModal( 'push' ) );
-	};


Why do we need to call refetchWpComSites here? If the goal is to refetch whenever the sync modal opens, would it not make more sense to call this from within the sync modal?

We could combine it with the refetchOnMountOrArgChange option to refetch the hook data when mounting.

I would say that's a matter of preference, I updated that motivated by this comment but I will investigate the result of using it when opening the sync modal and combining it with refetchOnMountOrArgChange

After doing the changes, it's clear that it was better to do it in the component, thanks for the suggestion! I have done it as part of 5079edf

fredrikekelund · 2025-12-02T12:19:29Z

src/hooks/sync-sites/use-listen-deep-link-connection.ts

I suggest moving more of this logic to src/stores/sync/connected-sites.ts by updating the connectSite mutation like so:

connectSite: builder.mutation< SyncSite[], { remoteSiteId: number; localSiteId: string; userId?: number } >( { queryFn: async ( { remoteSiteId, localSiteId, userId }, api ) => { const connectedSites = await getIpcApi().getConnectedWpcomSites( localSiteId ); const { data: remoteSites = [] } = await api.dispatch( wpcomSitesApi.endpoints.getWpComSites.initiate( { connectedSiteIds: connectedSites.map( ( site ) => site.id ), userId, } ) ); const siteToConnect = remoteSites.find( ( site ) => site.id === remoteSiteId ); if ( ! siteToConnect ) { return { error: { status: 'CUSTOM_ERROR', error: 'Site not found in WordPress.com sites' }, }; } await getIpcApi().connectWpcomSites( [ { sites: [ siteToConnect ], localSiteId, }, ] ); const actualConnectedSites = await getIpcApi().getConnectedWpcomSites( localSiteId ); return { data: actualConnectedSites }; },

This would allow us to shorten this hook significantly:

export function useListenDeepLinkConnection() { const [ connectSite ] = useConnectSiteMutation(); const { selectedSite, setSelectedSiteId } = useSiteDetails(); const { setSelectedTab, selectedTab } = useContentTabs(); const { user } = useAuth(); useIpcListener( 'sync-connect-site', async ( _event, { remoteSiteId, studioSiteId } ) => { if ( selectedSite?.id && selectedSite.id !== studioSiteId ) { // Select studio site that started the sync setSelectedSiteId( studioSiteId ); } await connectSite( { remoteSiteId, localSiteId: studioSiteId, userId: user?.id } ); if ( selectedTab !== 'sync' ) { // Switch to sync tab setSelectedTab( 'sync' ); } } ); }

Thanks for the suggestion, I will work on that

I have been working on this, but I have found that this will trigger an additional call to the /me/sites endpoint when the connectSite mutation is used from the add-site and from the ContentTabSync handleConnect, where they already have the site, so I am not sure we are improving here.

What do you think about tackling this specific refactor as a follow-up and progressing with the current changes?

fredrikekelund · 2025-12-02T12:23:13Z

src/modules/add-site/components/pull-remote-site.tsx

+	const { data: syncSites = [], refetch: refetchSites } = useGetWpComSitesQuery( {
+		connectedSiteIds,
+		userId: user?.id,
+	} );


Suggested change

const { data: syncSites = [], refetch: refetchSites } = useGetWpComSitesQuery( {

connectedSiteIds,

userId: user?.id,

} );

const { data: syncSites = [] } = useGetWpComSitesQuery(

{ connectedSiteIds, userId: user?.id },

{ refetchOnMountOrArgChange: true }

);

I believe we could remove the refetchSites call by passing the refetchOnMountOrArgChange flag here.

OK, I will have a look at it, I had that initially, but it was refetching the sites more than expected. I will check it again after latest updates.

I have done the changes as part of 61e8a4b, they do the same refetch on mount and we avoid the useEffect 👍

fredrikekelund · 2025-12-02T12:44:51Z

src/modules/sync/index.tsx

+			if ( isAuthenticated && ! isUninitializedSyncSites ) {
+				// Refetch sites on the background but ignore errors
+				void refetchWpComSites();
+			}


Instead of explicitly refetching in the handleOpenModal handler, I suggest adding another useGetWpComSitesQuery call in SyncSitesModalSelector. See my comment in that file for more details.

Yes, that's a better approach, I have implemented it as part of 5079edf

fredrikekelund · 2025-12-02T12:47:42Z

src/modules/sync/components/sync-sites-modal-selector.tsx

I suggest making it so that the useGetWpComSitesQuery hook is declaratively refetched by removing the syncSites prop from this component, and adding another call to the useGetWpComSitesQuery hook like so:

const { user } = useAuth(); const { data: connectedSites = [] } = useGetConnectedSitesForLocalSiteQuery( { localSiteId: selectedSite.id, userId: user?.id, } ); const connectedSiteIds = connectedSites.map( ( { id } ) => id ); const { data: syncSites = [] } = useGetWpComSitesQuery( { connectedSiteIds, userId: user?.id }, { refetchOnMountOrArgChange: true } );

The refetchOnMountOrArgChange option should accomplish the same thing as the refetch call in src/modules/sync/index.tsx

Agreed 😄 , I have done it as part of 5079edf

fredrikekelund · 2025-12-02T12:52:12Z

src/stores/sync/wpcom-sites.ts

+					// First transformation using all connected sites (for reconciliation)
+					const syncSitesForReconciliation = transformSitesResponse(
+						parsedResponse.sites,
+						allConnectedSites.map( ( { id } ) => id )
+					);
+
+					// whenever array of syncSites changes, we need to update connectedSites to keep them updated with wordpress.com
+					const { updatedConnectedSites } = reconcileConnectedSites(
+						allConnectedSites,
+						syncSitesForReconciliation
+					);
+					await getIpcApi().updateConnectedWpcomSites( updatedConnectedSites );
+
+					// Second transformation using connectedSiteIds parameter (for syncSupport calculation for selected site)


Suggested change

// First transformation using all connected sites (for reconciliation)

const syncSitesForReconciliation = transformSitesResponse(

parsedResponse.sites,

allConnectedSites.map( ( { id } ) => id )

);

// whenever array of syncSites changes, we need to update connectedSites to keep them updated with wordpress.com

const { updatedConnectedSites } = reconcileConnectedSites(

allConnectedSites,

syncSitesForReconciliation

);

await getIpcApi().updateConnectedWpcomSites( updatedConnectedSites );

// Second transformation using connectedSiteIds parameter (for syncSupport calculation for selected site)

const syncSitesForReconciliation = transformSitesResponse(

parsedResponse.sites,

allConnectedSites.map( ( { id } ) => id )

);

const { updatedConnectedSites } = reconcileConnectedSites(

allConnectedSites,

syncSitesForReconciliation

);

await getIpcApi().updateConnectedWpcomSites( updatedConnectedSites );

Nit, but the variable names are clear enough here that I would argue we could skip the line comments.

Done as part of 99a6b55

fredrikekelund · 2025-12-02T12:56:02Z

src/stores/sync/wpcom-sites.ts

+	};
+}
+
+function transformSitesResponse( sites: unknown[], connectedSiteIds: number[] ): SyncSite[] {


I know this function is the same as before, but I think the connectedSiteIds deserves a short explainer in a comment.

Done as part of 99a6b55

…a-for-users-without-sites-displays-before-sites-are-loaded

epeicher · 2025-12-02T19:03:45Z

Thanks @fredrikekelund for the review and the suggestions! I have implemented most of them and I still want to look at this one and this one. I will let you know when they are addressed and we can do another review 🙏

…he sites" This reverts commit 5cfc0f2.

…remote-site

…a-for-users-without-sites-displays-before-sites-are-loaded

epeicher · 2025-12-03T08:51:27Z

Hi @fredrikekelund, I have implemented most of your suggestions, and replied to one of the suggestions here. I have tested it again, but this will benefit from another testing and some review after latest changes.

Could you please give another round of review and let me know if you find any issues? 🙏

fredrikekelund · 2025-12-03T09:39:12Z

Taking a look now 👀

epeicher added 3 commits November 25, 2025 20:27

Implement RTK Query approach for fetching wpcom sites

c4efc6c

Use the new hook and update loading conditions

7d8fd66

Rename function name for clarity

ba89f0d

wojtekn assigned epeicher Nov 26, 2025

epeicher added 2 commits November 26, 2025 20:16

Remove use-fetch-wpcom-sites and update imports

ee7ea22

Fix tests

afd3fbf

epeicher marked this pull request as ready for review November 26, 2025 19:53

sejas reviewed Nov 26, 2025

View reviewed changes

epeicher added 4 commits November 27, 2025 11:46

Refetch sites when opening the sites modal instead of using an effect

d7113b1

Do not fetch sites on mount

9a6f74f

Merge branch 'trunk' of github.com:Automattic/studio into stu-1035-ct…

7d0b2a5

…a-for-users-without-sites-displays-before-sites-are-loaded

Update files after merge

b09206b

epeicher commented Nov 27, 2025

View reviewed changes

sejas reviewed Nov 28, 2025

View reviewed changes

epeicher added 4 commits November 28, 2025 18:41

Infer the SitesEndpointSite type from the schema

427d3ab

Remove unnecessary effect on sites modal

63cc6b8

Merge branch 'trunk' of github.com:Automattic/studio into stu-1035-ct…

48ffd67

…a-for-users-without-sites-displays-before-sites-are-loaded

Unify Publish site button in one component with a redirect prop

7e1bbdb

katinthehatsite reviewed Dec 1, 2025

View reviewed changes

epeicher added 2 commits December 1, 2025 18:56

Fix comment wording

c86048c

Remove isBusy from the publish site button

b134968

The query is executed in the background so it is not required to indicate that in the button

fredrikekelund reviewed Dec 2, 2025

View reviewed changes

epeicher added 3 commits December 2, 2025 16:58

Merge branch 'trunk' of github.com:Automattic/studio into stu-1035-ct…

5610e0e

…a-for-users-without-sites-displays-before-sites-are-loaded

Move fetching sites logic to sites modal selector

5079edf

Add and remove comments

99a6b55

Refactor connected-sites mutation to accept an id and fetch the sites

5cfc0f2

epeicher added 3 commits December 3, 2025 09:32

Revert "Refactor connected-sites mutation to accept an id and fetch t…

8fa10dd

…he sites" This reverts commit 5cfc0f2.

Use the more declarative refetchOnMount instead of an effect on pull-…

61e8a4b

…remote-site

Merge branch 'trunk' of github.com:Automattic/studio into stu-1035-ct…

a2fd40a

…a-for-users-without-sites-displays-before-sites-are-loaded

	// Schema type for WordPress.com sites endpoint
	export type SitesEndpointSite = {
	ID: number;
	is_wpcom_atomic: boolean;
	name: string;
	URL: string;

	// Refetch sites on the background but ignore errors
	// Refetch sites in the background but ignore errors

Implement RTK Query approach for fetching wpcom sites #2132

Are you sure you want to change the base?

Implement RTK Query approach for fetching wpcom sites #2132

Conversation

epeicher commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related issues

Before

After

Proposed Changes

Testing Instructions

Pre-merge Checklist

Uh oh!

github-actions bot commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📊 Performance Test Results

site-editor

site-startup

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sejas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sejas Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

katinthehatsite left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epeicher commented Dec 1, 2025

Uh oh!

fredrikekelund left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epeicher commented Nov 25, 2025 •

edited

Loading

github-actions bot commented Nov 26, 2025 •

edited

Loading

sejas Nov 28, 2025 •

edited

Loading

katinthehatsite left a comment •

edited

Loading

epeicher Dec 2, 2025 •

edited

Loading

epeicher Dec 2, 2025 •

edited

Loading

epeicher commented Dec 2, 2025 •

edited

Loading