The current implementation of the MEX / wbui2025 user interface has relatively complicated state management for changes-in-progress that is mutated within various different components in an unintuitive way. @Lucas_Werkmeister_WMDE suggests that:

• there’s too much happening in the components, it should move into the store
• there should be a separate store (in the same Pinia instance) from the statementsStore; data should only move back into the statementsStore when the edit has been saved
• (these two, together, should hopefully get rid of a lot of the current Object.assign( {}, … ) and JSON.parse( JSON.stringify( … ) ) stuff that’s keeping the in-progress edits out of the statementsStore at the moment)

Additionally:

• the “statement being edited” store should primarily contain the values in a form that can be directly bound to the text inputs, i.e. not yet in parsed data value form
• separately, there should be a store (cache?) of parsed data values (property ID → string input → Promise for parsed response); when the user types into the input, we send out the wbparsevalue request and put it in this store
• the publish button should be enabled if the parsed data value store contains resolved responses for all the currently used text inputs (and at that point we can then also check if it’s actually different from the currently saved value in the statementsStore, and disable the button if the user’s input results in no change to the saved value, e.g. only adding surrounding whitespace)
• publishing the edit pulls the corresponding parsed data values out of that cache (for the main value, qualifiers, and references) and then assembles the entity in the format we send to wbeditentity

Acceptance Criteria

• wbui2025 code should be refactored to use a second pinia store for work-in-progress edits
• the refactor should incorporate the above feedback / observations

The Acceptance Criteria regarding wbparsevalue and the publish button have been moved to T405238