Text changes

[lightninglu10]

Refactor: Streamline Element Change Processing

This PR refactors the element change processing logic in src/server.js to simplify how text changes are handled.

Key Changes:

• Removed redundant logic that previously derived text_changes from old_html and new_html properties within an element change object.
• Directly assigns change.text_changes to elementChange.text_changes, assuming text_changes are now explicitly provided by the caller.

Review Notes:

• This change assumes that text_changes are now directly provided in the change object from upstream. Reviewers should verify if this assumption holds true across all call sites that interact with this element change processing logic.
• Consider adding specific tests to cover scenarios where old_html/new_html might still be present but text_changes are not, to ensure no data loss.

[github-actions]

❇️ CodePress Review Summary

👋 Hey team,

Overall the changes look solid, but I spotted 1 must-fix issue and left 0 helpful notes inline.

Here's the quick rundown:

❌ Decision: REQUEST CHANGES
The change introduces a new assumption about the input change object structure which could be a breaking change. Verification of all call sites and updated test coverage is required.

🚧 Needs a bit of love

The primary concern is a potential data loss stemming from an implicit assumption that change.text_changes will always be directly provided. If text_changes was previously derived from old_html and new_html, this change could lead to missing data. It is crucial to trace all call sites where the change object is constructed to ensure text_changes is correctly populated, and any breaking API changes should be explicitly documented.

[github-actions]

🔴 REQUIRED: This change assumes change.text_changes is always provided directly. If old_html and new_html were previously used to generate text_changes and text_changes was not explicitly set, this could lead to a loss of text change data. The dep_graph tool shows that src/cli.js imports src/server.js. The fetch_file tool shows that src/cli.js only calls startServer(), it does not construct the change object. Therefore, it's highly likely that the change object is constructed and passed to src/server.js from another module that isn't directly imported by src/server.js or src/cli.js.

To verify all call sites, you'd need to trace where the change object is created and ensure text_changes is populated correctly there. If this is a breaking change in the API, it should be explicitly documented.