Skip to content

[WIP]: Add the rewind FileBrowser to the Sync Modal #104511

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 6 commits into
base: trunk
Choose a base branch
from

Conversation

epeicher
Copy link
Contributor

@epeicher epeicher commented Jun 30, 2025

Related to DOTDEV-178

Proposed Changes

  • Add the FileBrowser component from Jetpack Backups to allow granular synchronization
  • Add the queries to populate the FileBrowser
  • Add the handler to the Pull button in the SyncModal to initiate the Synchronization

CleanShot 2025-07-01 at 14 06 32@2x

Why are these changes being made?

  • To complete the happy path of the granular synchronization project

Testing Instructions

  • Apply these changes and start Calypso, that will enable the feature flag hosting/staging-sites-redesign
  • Make sure you have a Production with a linked Staging site, more info here
  • Navigate to the staging site, and click on the Sync dropdown on the top-right corner
  • Select Push to Production
  • On the opened modal, select a number of folders and click on Push
  • The notification functionality is not implemented yet, so you need to close the Modal manually and refresh
  • Check that the Synchronization process start
  • Get the blog_id of the production site and check the logs using Rewind Logs - PCYsg-_qeJ-p2
  • Check that the process completes and only the selected folders are synchronized

Pre-merge Checklist

  • Has the general commit checklist been followed? (PCYsg-hS-p2)
  • Have you written new tests for your changes?
  • Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
  • Have you checked for TypeScript, React or other console errors?
  • Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
  • Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
  • Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
    • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
  • For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

Copy link

github-actions bot commented Jun 30, 2025

@matticbot
Copy link
Contributor

matticbot commented Jun 30, 2025

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~40 bytes removed 📉 [gzipped])

name                    parsed_size           gzip_size
entry-main                   -489 B  (-0.0%)      -45 B  (-0.0%)
entry-subscriptions           -98 B  (-0.0%)      +60 B  (+0.0%)
entry-stepper                 -98 B  (-0.0%)      +64 B  (+0.0%)
entry-reauth-required         -98 B  (-0.0%)      +60 B  (+0.0%)
entry-login                   -98 B  (-0.0%)      +60 B  (+0.0%)
entry-domains-landing         -98 B  (-0.0%)      +60 B  (+0.0%)
entry-dashboard-dotcom        -98 B  (-0.0%)      +61 B  (+0.0%)
entry-dashboard-a4a           -98 B  (-0.0%)      +61 B  (+0.0%)
entry-browsehappy             -98 B  (-0.0%)      +60 B  (+0.1%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~52151 bytes added 📈 [gzipped])

name                            parsed_size           gzip_size
site-performance                   +70758 B  (+4.5%)   +20570 B  (+4.6%)
site-monitoring                    +70758 B  (+5.2%)   +20701 B  (+5.3%)
github-deployments                 +70758 B  (+5.1%)   +20597 B  (+5.3%)
sites-dashboard                    +70578 B  (+5.6%)   +21060 B  (+6.0%)
site-logs                          +70448 B  (+5.0%)   +20714 B  (+5.3%)
staging-site                       +68591 B  (+4.6%)   +19878 B  (+4.8%)
domains                            +62588 B  (+1.7%)   +17852 B  (+1.9%)
site-settings                      +57488 B  (+3.4%)   +16213 B  (+3.4%)
hosting                            +57488 B  (+2.9%)   +16213 B  (+3.0%)
overview                           +55006 B  (+1.9%)   +14725 B  (+1.9%)
plans                              +49053 B  (+2.2%)   +12539 B  (+1.9%)
backup                               +912 B  (+0.1%)     -942 B  (-0.3%)
a8c-for-agencies-sites               +912 B  (+0.0%)     -942 B  (-0.1%)
signup                               +596 B  (+0.2%)      +47 B  (+0.1%)
async-step-unified-plans             +596 B  (+0.0%)      +44 B  (+0.0%)
async-step-unified-domains           +596 B  (+0.0%)      +43 B  (+0.0%)
reader                               -338 B  (-0.0%)     +350 B  (+0.0%)
settings                             -196 B  (-0.0%)     -848 B  (-0.3%)
activity                             -127 B  (-0.0%)    -1046 B  (-0.5%)
settings-jetpack                     +115 B  (+0.0%)      -75 B  (-0.0%)
devdocs                              -108 B  (-0.1%)      -18 B  (-0.0%)
settings-security                    +107 B  (+0.0%)     -528 B  (-0.3%)
jetpack-cloud-agency-dashboard        -71 B  (-0.0%)     -227 B  (-0.1%)
scan                                  -56 B  (-0.0%)     -593 B  (-0.2%)
jetpack-cloud-settings                -56 B  (-0.0%)     -987 B  (-0.5%)
import                                -26 B  (-0.0%)       +8 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~661 bytes removed 📉 [gzipped])

name                                       parsed_size           gzip_size
async-load-design-blocks                        -183 B  (-0.0%)     -795 B  (-0.1%)
async-load-signup-steps-clone-ready             +125 B  (+0.2%)     +377 B  (+1.6%)
async-load-comment-block-editor                 +103 B  (+0.0%)     +170 B  (+0.0%)
async-load-signup-steps-clone-point              -71 B  (-0.0%)     -253 B  (-0.6%)
async-load-signup-steps-rewind-form-creds        +57 B  (+0.1%)     +264 B  (+0.9%)
async-load-signup-steps-clone-credentials        +57 B  (+0.1%)     +264 B  (+0.9%)
async-load-signup-steps-creds-permission         +37 B  (+0.0%)      -43 B  (-0.2%)
async-load-signup-steps-creds-confirm            +37 B  (+0.0%)      +25 B  (+0.1%)
async-load-signup-steps-domains                  -13 B  (-0.0%)       +6 B  (+0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

@matticbot
Copy link
Contributor

matticbot commented Jul 1, 2025

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

  • blaze-dashboard
  • command-palette-wp-admin
  • help-center
  • notifications
  • odyssey-stats

To test WordPress.com changes, run install-plugin.sh $pluginSlug dotdev-178-implement-the-frontend-design-of-the-granular-sync on your sandbox.

@epeicher
Copy link
Contributor Author

epeicher commented Jul 1, 2025

Hi @Automattic/lego,

This PR is currently a work in progress, but I would like to have early feedback from you as I am breaking some principles as a pragmatic approach.

The problem we are trying to solve is to have granular synchronization between Production and Staging sites, so the user can synchronize specific folders. This can be achieved using the Jetpack Rewind functionality, and that functionality uses the FileBrowser component that I am adding as part of this PR. The FileBrowser populates the file tree from the latest backups, and, when selecting any node, it returns the paths in the form expected by VaultPress, so they can be passed as a parameter to the endpoint.

That FileBrowser component breaks some principles from the Dashboard, as it is a Calypso component, it relies on CSS, and it uses Redux for state management. It also requires one Query component to populate the tree. But we would benefit from having one component that has been battle-tested, and it receives active maintenance.

The long-term solution could be to remove Redux and the external CSS from the FileBrowser component, but that would need to be coordinated with VaultPress team

What is your view about that? Do you think we can accept this FileBrowser as an isolated legacy component? Please ping me directly in Slack for any questions if you prefer.

@fushar
Copy link
Contributor

fushar commented Jul 1, 2025

👋 Hello hello, thanks for checking!

Unfortunately, using the redux store is a strict NO in the new dashboard code, as it will pull can of worms to the bundle. For this case, the current workaround is to move the entire staging-site-sync-modal outside the client/dashboard/ (e.g. back to client/sites/staging-site/), then async-load the modal from the dropdown code. Later, we can start refactoring the code to not depend on the store.

See a previous attempt for reference: https://github.com/Automattic/wp-calypso/pull/104267/files#diff-948eb1bc6a1f66eb77415f4d3530716c900aba197ea0672536d8f95fb28a80b8R112

Let us know if there's any more doubt!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants