Revert "Implement GutenbergKit ViewModel Architecture (#22087)"

[oguzkocer]

Summary

Reverts the GutenbergKitViewModel implementation as it may create configuration change issues and adds complexity without clear benefits.

Note that this was a clean revert, so it doesn't include any additional changes.

Reason

The ViewModel approach mixes static configuration with dynamic content and could cause state synchronization problems. The Bundle-based approach is simpler and more appropriate for passing initialization parameters.

Testing Instructions

Check for any regressions.

[dangermattic]

	1 Warning
⚠️	This PR is assigned to the milestone 26.1. The due date for this milestone has already passed. Please assign it to a milestone with a later deadline or check whether the release for this milestone has already been finished.

Generated by 🚫 Danger

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wpmobilebot]

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

	App Name	WordPress
	Flavor	Jalapeno
	Build Type	Debug
	Version	pr22127-b637fad
	Commit	b637fad
	Direct Download	wordpress-prototype-build-pr22127-b637fad.apk

Note: Google Login is not supported on these builds.

[wpmobilebot]

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

	App Name	Jetpack
	Flavor	Jalapeno
	Build Type	Debug
	Version	pr22127-b637fad
	Commit	b637fad
	Direct Download	jetpack-prototype-build-pr22127-b637fad.apk

Note: Google Login is not supported on these builds.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 39.43%. Comparing base (cbbde75) to head (b637fad).
⚠️ Report is 1 commits behind head on release/26.1.

Additional details and impacted files

@@              Coverage Diff              @@
##           release/26.1   #22127   +/-   ##
=============================================
  Coverage         39.43%   39.43%           
=============================================
  Files              2149     2149           
  Lines            101872   101872           
  Branches          15604    15604           
=============================================
  Hits              40177    40177           
  Misses            58126    58126           
  Partials           3569     3569           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dcalhoun]

I did not encounter any regressions while smoke testing GutenbergKit.

The ViewModel approach mixes static configuration with dynamic content and could cause state synchronization problems. The Bundle-based approach is simpler and more appropriate for passing initialization parameters.

For my own understanding, would you mind sharing an explicit example(s) of synchronization problems? Are they severe or prevalent enough to target the beta branch?

[oguzkocer]

For my own understanding, would you mind sharing an explicit example(s) of synchronization problems? Are they severe or prevalent enough to target the beta branch?

@dcalhoun This is a precautionary revert, rather than addressing a bug I've found. While working on EditPostActivity, and specifically that regression you've reported, I am better understanding how the pieces fit together.

The way GutenbergKitViewModel is used at the moment creates architectural concerns, because we don't use the reactive nature of the live data and only hold the settings. The problem is that those settings include static settings, such as the siteUrl, locale etc, but also dynamic ones such as postTitle, postContent etc. The activity life cycles, fragment restorations and the fact that view models survive configuration changes mean that there are possible cases where the View Model may contain stale data. This is probably preventable, and may not be happening at the moment, but we'd need to pay extra attention to it. On the other hand, the previous solution did not have these issues and since the view model is not currently adding any value, I believe it's best to revert it.

As for whether to target the frozen branch or not, I think there is a trade-off:

• If we revert, it's a clean one and we only go back to where we were just prior to code freeze. However, we don't get the testing benefit from the beta cycle.
• If we don't revert, we use the beta tested version, but we might be introducing edge cases. If we revert this in trunk, the data that we collect for this version - for example bug reports - will not be as valuable because there will always be the possibility of the View Model change being the root cause.

Considering this is behind an experimental flag, I believe it'd be best to revert this in the frozen branch. In my opinion, we want to be as close to the final version as possible in every release we do for this experimental feature to get the most out of this period.

What do you think?

[dcalhoun]

@oguzkocer thank you for elaborating on the context and rationale. I agree, it makes sense to revert in the release branch.