Refresh the RS post and page lists when FluxC changes a post - #23235
Conversation
The rs collections only see changes rs itself made, so a post saved in the editor stayed stale in the list until the user pulled to refresh. RsPostChangeListener bridges the FluxC post events until wordpress-rs can report those changes itself.
Generated by 🚫 Danger |
|
|
|
|
🤖 Build Failure AnalysisThis build has failures. Claude has analyzed them - check the build annotations for details. |
Guard start/stop so a view model that never selected a site doesn't unregister a listener it never registered, subscribe to the change flow before starting the listener so a change can't land before the collector does, and move the post-changed handler off the main thread since deciding whether a post belongs to the list reads it back from the DB.
Detekt caps a function at two return statements.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## trunk #23235 +/- ##
==========================================
+ Coverage 37.94% 37.97% +0.03%
==========================================
Files 2334 2336 +2
Lines 127138 127214 +76
Branches 17609 17627 +18
==========================================
+ Hits 48241 48312 +71
- Misses 74952 74956 +4
- Partials 3945 3946 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Most FluxC changes arrive while the editor covers the list, so refreshing then spends a request per open tab on a screen nobody is looking at. A hidden list now records that it is out of date and refreshes once when it is shown again. RsTabRefreshJobs holds each tab to one refresh at a time, since two concurrent refreshes of a collection would each replace the other's metadata, and replays a request that arrived mid-refresh because the running one may have asked the server before the change landed.
Deferring only when the list was hidden meant a change arriving while it was visible but offline was dropped, never to be refreshed. Remembering it in both cases collapses the three functions the deferral was spread over into one and makes the list catch up when it is next shown.
|
This is odd. I update a post title and it's not reflected in the list even if I pull to refresh 🤔 screen-20260819-164746-1787150857105.mp4 |
That is definitely odd, but I'm not able to reproduce it. If you visit the blog's web site, did the changes get saved? It might be worth running the network inspector to see if anything is failing. untitled.webm |
|
This is odd because I cannot even create a post. Screen_recording_20260819_172737.mp4 |
|
Update: The upload failures aren't due to changes in this PR. Actual problem filed in Linear CMM-2331. |
|
Tested with a non-Jurassic-ninja site and it works as expected. Just one note: when I create a new post, the list does not scroll to the top. I can slightly see there's a new card at the top, but I have to scroll the list to see the new post. Is that something we can improve? screen-20260820-101626-1787213755495.mp4 |
I filed a separate issue for this. It was waiting for the fix in this PR before it could be tackled. |
adalpari
left a comment
adalpari
left a comment
There was a problem hiding this comment.
There seems to be a CI issue, but overall LGTM!
4 participants
Description
TL/DR: the wordpress-rs post and page lists never noticed edits made in the editor. This PR adds a temporary FluxC bridge so they refresh themselves. Once the editor switches to wp-rs we can remove this in favor of an RS-based solution.
The rs lists are driven by an rs
ObservableMetadataCollection, which only sees changes rs itself made. The editor andUploadServicewrite through FluxC, so a post edited in the editor stayed stale in the list until the user pulled to refresh. The posts list subscribed to nothing at all; the pages list had a single ad-hocOnPostUploadedhandler added for the duplicate-page flow.New
RsPostChangeListeneris the whole bridge — one file, injected into both view models, so when wordpress-rs can report these changes itself it's one deletion plus two constructor params. It reportsOnPostUploaded, and theOnPostChangedcauses that mean the server copy changed (UpdatePostwithisLocalUpdate = false,DeletePost,RestorePost), filtered by site and post-vs-page. Emissions are debounced 500ms because a WP.com publish fires two events back to back.RemoteAutoSavePostis deliberately ignored — it stores a revision and leaves the published post the list renders untouched, and it's the common "back out of the editor without tapping Update" path. So isUpdatePostwithisLocalUpdate = true, which fires on every debounced keystroke in the editor.The pages list's inline handler is removed in favour of the shared one, which also gives it the
OnPostChangedcoverage it didn't have.Three things worth knowing when reading the listener:
onPostChangedis delivered onThreadMode.BACKGROUND, because deciding whether a post belongs to this list means reading it back out of the database and the event fires on every write FluxC makes.onPostUploadedstays onMAIN— the event already carries thePostModel. The fields both handlers read are@Volatileaccordingly.changesbefore callingstart(): the flow has no replay, so an event arriving before the collector subscribes is dropped.stop()is safe whether or notstart()was ever reached, which matters because the view models clear unconditionally but only start when a site is selected.onStart.Also fixed here, because this PR is what makes it reachable without user action:
refreshTab()had no in-flight guard, so a pull-to-refresh and an automatic refresh could runcollection.refresh()concurrently on the same collection and each replace the other's metadata.RsTabRefreshJobsnow holds a tab to one refresh at a time and replays a request that arrived mid-flight, since the running refresh may have asked the server before the change landed.Out of scope: upload-progress and upload-error UI. The legacy lists use
PostEvents/UploadServiceevents for in-flight and failed badges — the rs lists have no such UI.Testing instructions
Requires a site with an application password, so the rs lists are used.
Post list updates after an edit:
New post appears:
Page duplication still works: