Move pull and push states from SyncSitesProvider to a new Redux slice

[gcsecsey]

Related issues

Fixes STU-711

Proposed Changes

• Removed SyncSitesProvider completely
• Added a new syncOperations Redux slice
• Moved logic from use-sync-pull and use-sync-push hooks to Redux thunks
• Kept the hooks as think wrappers of the tunks
• Removed some unused callback props

Testing Instructions

• Run npm start
• Go to the Sync tab
• Connect a site
• Pull changes from the site and check that there are no regressions
• Push changes to the site and check that there are no regressions

Pre-merge Checklist

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

[github-actions]

📊 Performance Test Results

Comparing 3ceedf4 vs trunk

site-editor

Metric	trunk	3ceedf4	Diff	Change
load	6749.00 ms	6460.00 ms	-289.00 ms	🟢 -4.3%

site-startup

Metric	trunk	3ceedf4	Diff	Change
siteCreation	9081.00 ms	16122.00 ms	+7041.00 ms	🔴 77.5%
siteStartup	3952.00 ms	3956.00 ms	+4.00 ms	🔴 0.1%

---

Results are median values from multiple test runs.

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

[nightnei]

Push: it seems it stucks at "Creating backup..." step. Tried a few times and also tried in trunk - worked quickly for me.

Pull: not related to the changes, since I reproduce the error in trunk too, but if you are working there - take a look please at this error when pull is finished, maybe it's a quck win:

[gcsecsey]

Push: it seems it stucks at "Creating backup..." step. Tried a few times and also tried in trunk - worked quickly for me.

Pull: not related to the changes, since I reproduce the error in trunk too, but if you are working there - take a look please at this error when pull is finished, maybe it's a quck win:

Thanks for reviewing this @nightnei! I took another look at this, and found that earlier we used a ref to keep track of the state, which let us read it back immediately after updating it. For now, I added the ref to the hooks that were previously in the usePullPushStates hook.

I'm also testing a simpler approach that updated the state objects directly where needed. If it works reliably, I'll update the PR with this approach.

[fredrikekelund]

@gcsecsey, I would challenge us to remove src/hooks/sync-sites/sync-sites-context.tsx completely as part of this refactor.

With this change, we are preserving functions like updatePushState in the React context, even though they are now essentially Redux action creators (or thunks, I guess). The logic around sync operations would be much easier to follow if we moved src/hooks/sync-sites/use-sync-push.ts and src/hooks/sync-sites/use-sync-pull.ts into src/stores/sync/sync-operations-slice.ts.

[gcsecsey]

@gcsecsey, I would challenge us to remove src/hooks/sync-sites/sync-sites-context.tsx completely as part of this refactor.

With this change, we are preserving functions like updatePushState in the React context, even though they are now essentially Redux action creators (or thunks, I guess). The logic around sync operations would be much easier to follow if we moved src/hooks/sync-sites/use-sync-push.ts and src/hooks/sync-sites/use-sync-pull.ts into src/stores/sync/sync-operations-slice.ts.

That's a good point @fredrikekelund, thanks! I'll try to move as much as possible to the Redux slice, and ping for another review.

[gcsecsey]

I carried out the changes to move most of the logic into thunks within src/stores/sync/sync-operations-slice.ts. I experimented with removing the src/hooks/sync-sites/use-sync-push.ts and src/hooks/sync-sites/use-sync-pull.ts hooks completely too, and update the components to directly use the thunks, but I found this needed quite a bit of boilerplate in each component, so for the time being, I kept the hooks as thin wrappers.

@fredrikekelund could you please take another look when you're back? Thanks!

[nightnei]

Thanks for addressing feedback, works well now, no regressions 👍

[gcsecsey]

I tested the changes again after resolving conflicts, the pull/push functionality still works as before. We can proceed with merging this as soon as the project process is 🟢 again.

[fredrikekelund]

Trunk is open for merge again. I'll happily review this PR this afternoon, though

[gcsecsey]

Trunk is open for merge again. I'll happily review this PR this afternoon, though

Thanks @fredrikekelund, that'd be great!

[fredrikekelund]

Looking into this now. At first glance, I'm a little skeptical to keeping src/hooks/sync-sites/use-sync-pull.ts and src/hooks/sync-sites/use-sync-push.ts as thin wrappers, but maybe I'll be swayed when looking more closely at the code.

To me, the end goal is to move "business logic" into Redux slices and have components focused on consuming the Redux-derived state, with as little data crunching as possible. The useSyncPull and useSyncPush hooks don't exactly contradict that, so maybe it just irks me that they seem like leftovers at first glance…

Anyway, you mentioned the need for additional boilerplate in components if we removed those hooks, @gcsecsey. Is that stuff like useAppDispatch and useAuth calls, or something else? The boilerplate in useSyncPull and useSyncPush looks manageable to me, if that's anything to judge by.

[gcsecsey]

Looking into this now. At first glance, I'm a little skeptical to keeping src/hooks/sync-sites/use-sync-pull.ts and src/hooks/sync-sites/use-sync-push.ts as thin wrappers, but maybe I'll be swayed when looking more closely at the code.

To me, the end goal is to move "business logic" into Redux slices and have components focused on consuming the Redux-derived state, with as little data crunching as possible. The useSyncPull and useSyncPush hooks don't exactly contradict that, so maybe it just irks me that they seem like leftovers at first glance…

Anyway, you mentioned the need for additional boilerplate in components if we removed those hooks, @gcsecsey. Is that stuff like useAppDispatch and useAuth calls, or something else? The boilerplate in useSyncPull and useSyncPush looks manageable to me, if that's anything to judge by.

Yes, exactly, I wanted to avoid having to add these as dependencies to each component. I think the boilerplate would be the useAppDispatch, useAuth, and pushStatesProgressInfo hooks, as these are needed when dispatching the pullSite or pushSite thunks currently. I also migrated some functions like isAnySitePushing to selectors, and the hook now just wraps this call to avoid the useRootSelector dependency on each call site.