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)
- 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 publish button and publish functionality should be refactored to parse values before submitting them to wbeditentity (see also T405238)