fix: Avoid unexpectedly marking post content as unsaved

[dcalhoun]

The custom editorHasChanges implementation resulted in an
always-"dirty" state, even after saving changes via the "Update" or
"Save draft" buttons. This removal, results in the editor relying upon
the existing editorHasChanges implementation, which appears to be more
accurate.

WordPress-iOS/WordPress/Classes/ViewRelated/Post/PostEditor.swift

Lines 81 to 83 in 388dbb1

	var editorHasChanges: Bool {
	!post.changes.isEmpty
	}

Fixes https://github.com/Automattic/dotcom-forge/issues/10114.

To test:

1: Update published posts

1. Open an existing, published post with the experimental editor.
2. Update the content.
3. Tap the "Update" button in the top right.
4. After the post saves, tap the back button in the top left.
5. Verify the app does not prompt save or discard unsaved changes.

2: Update draft posts

1. Open an existing, draft post with the experimental editor.
2. Update the content.
3. Tap the more button (three vertical dots) in the top right.
4. Tap the "Save Draft" button.
5. After the post saves, tap the back button in the top left.
6. Verify the app does not prompt save or discard unsaved changes.

Regression Notes

1. Potential unintended areas of impact
   Introduce post state bugs.
2. What I did to test those areas of impact (or what existing automated tests I relied on)
   Manually test creating/saving/updating/publishing posts.
3. What automated tests I added (or what prevented me from doing so)
   Deemed unnecessary for the experimental editor.

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Testing checklist:

• WordPress.com sites and self-hosted Jetpack sites.
• Portrait and landscape orientations.
• Light and dark modes.
• Fonts: Larger, smaller and bold text.
• High contrast.
• VoiceOver.
• Languages with large words or with letters/accents not frequently used in English.
• Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• iPhone and iPad.
• Multi-tasking: Split view and Slide over. (iPad)

[dangermattic]

	1 Warning
⚠️	PR is not assigned to a milestone.

Generated by 🚫 Danger

[kean]

These changes look good. The previous implementation was temporary. As you noted, the default implementation should be enough.

Some background: post.changes.isEmpty uses RemotePostUpdateParameters to detect changes. The changes include both changes to the content and the post settings. It relies of post.content and title being updated by the editor periodically and reliably. As long as the editor does so, it should be good.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr23969-1f14175
	Version	25.6
	Bundle ID	org.wordpress.alpha
	Commit	1f14175
	App Center Build	WPiOS - One-Offs #11342

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr23969-1f14175
	Version	25.6
	Bundle ID	com.jetpack.alpha
	Commit	1f14175
	App Center Build	jetpack-installable-builds #10373

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[dcalhoun]

Some background: post.changes.isEmpty uses RemotePostUpdateParameters to detect changes. The changes include both changes to the content and the post settings. It relies of post.content and title being updated by the editor periodically and reliably. As long as the editor does so, it should be good.

@kean thank you for providing that helpful context.

I was unsure about the rationale for the custom implementation. From my testing, using the default implementation works as expected. FYI, a similar approach was taken for the editorHasContent variable in https://github.com/wordpress-mobile/WordPress-iOS/pull/23631/files#r1779114670.

[kean]

I was unsure about the rationale for the custom implementation.

Tbh, I don't remember. I think it was needed for an early prototype where the editor couldn't communicate the content changes to the app. Out of curiosity, how is it done now?

[dcalhoun]

Out of curiosity, how is it [communicating content changes to the app] done now?

A generic store subscription broadcasts content changes to the host app. The host app throttles persisting the changes. There is likely opportunity to improve this approach.

[kean]

The host app throttles persisting the changes. There is likely wordpress-mobile/GutenbergKit#23 (comment) this approach.

The autosave is performed very infrequently. Its main purpose is to periodically write to disk to protect content from a crash. The assumption is that converting blocks to strings and transferring those from the editor to the app is expensive, so we avoid doing it as much as possible.

Am I correctly interpreting this code updates the host app on every store change? Are there potential performance implications to this approach?

It will need some performance testing, but AFAIK it shouldn't be an issue as long as there are no expensive calculations. It will keep the app (navigation bar) state up to date, which is nice, but this is not the case in Gutenberg Mobile.

The idea in NewGutenbergViewController was to avoid transferring post content between the app and the web as much as possible. The app doesn't need the latest content during editing. It does need it when you invoke an action, such as "Save Draft". In this case, the app pulls the latest content using performAfterUpdatingContent, which is fine because it doesn't happen during editing and any delays will be unnoticeable by the user.

If the editor needs to transfer some state in "real time", it should use EditorState. It's lightweight, and it takes no time to decode/encode, so it can be used freely and frequently.