Experiment to speed up deeplink connection from WP.com

[katinthehatsite]

Related issues

Related to STU-1173

Proposed Changes

This PR explores the speeding up of the deeplink connection from WP.com e.g. connecting a WP.com site and opening a modal. In this PR, I am using an optimistic connection approach:

• immediately create a minimal site object with data from the deeplink (this would need to be done on WP.com side, but we can add WP.com site's URL and site name which would be enough for our UI)
• connect it to storage right away
• and trigger the API refetch in parallel without blocking

Testing Instructions

• Pull the changes from this branch
• Start Studio
• Navigate to the Sync tab
• Make sure that you don't have any WP.com sites connected to your Studio site so that the Publish site button displays in the top right corner
• Click on the Publish site button
• Observe that you are brought to WP.com
• Complete the purchase
• Wait for the site to go Atomic
• Observe that you see a popup asking you to open Studio
• Confirm that the site you just created is connected in the Sync tab
• Initially, you will see Loading site... placeholder and no URL in the Sync tab (because we need to pass these from Calypso and that needs to be done in the separate PR)
• Confirm that the Push modal is open

Pre-merge Checklist

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

[wpmobilebot]

📊 Performance Test Results

Comparing 11f9f3b vs trunk

site-editor

Metric	trunk	11f9f3b	Diff	Change
load	7578.00 ms	6869.00 ms	-709.00 ms	🟢 -9.4%

site-startup

Metric	trunk	11f9f3b	Diff	Change
siteCreation	9094.00 ms	9067.00 ms	-27.00 ms	🟢 -0.3%
siteStartup	3955.00 ms	3953.00 ms	-2.00 ms	🟢 -0.1%

---

Results are median values from multiple test runs.

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

[katinthehatsite]

The code needs to be polished quite a bit so I am leaving this PR as a draft. What I am looking for is the feedback on the approach before adding any further polishing touches - does it make sense? is there a different way we could optimize the speed of connection that could be simpler?

One thing I dislike is creating a "fictional" site object that could potentially cause racing conditions and similar issues. Any opinions are welcome!

One option as an alternative that comes to mind could be adding a loading state to Sync tab if the user is connecting a site from deeplink and it is taking time. This way, they could have a visual indication of what is happening and this could be a simple and fast improvement in terms of the UX.

[sejas]

Thanks for exploring how to speed up the deeplink connection.
In general the approach makes sense to me. Loading an optimistic connection until we fetch more information.
My concern is if we display wrong data, like isStaging, or isPressable. With the current flow where the user purchase a new site, those will always be false, but in the future we could add more deeplinks in Calypso.
What if we show a loading skeleton until we fetch the information?
As mentioned below, we can optimize the fetch call to get only the information for that specific site.

[sejas]

Another optimization could be fetching only the information of the remoteSiteId. Currently fetching all the sites takes longer, specially for Automatticians.

[sejas]

We need to translate the placeholder.