Page MenuHomePhabricator

Research statement saving
Closed, ResolvedPublic

Description

Find out how statements are updated/saved

Timebox: 4h

Helpful research directions:

Event Timeline

noarave created this task.Sep 6 2019, 10:19 AM
noarave updated the task description. (Show Details)Sep 6 2019, 1:06 PM
noarave added a comment.EditedSep 9 2019, 8:12 AM

Assuming we are interested in knowing when a statement's value have been changed, here's what I was able to find so far:

  • StatementChanger.js method save() has the object statement where the element claim (originates in Claim.js) lies.
  • extensions/Wikibase/view/lib/wikibase-data-model/src/Claim.js contains the methods getClaim() and getMainSnak() but not a way to get the actual value entered. So we might want to start with adding that?

It should then be possible to compare that with the preexisting value and see if there was a change.

Tarrow added a subscriber: Tarrow.Sep 9 2019, 12:55 PM

We are imagining perhaps altering StatementChanger.js with something like

				// Step 1 introduce:
				self._fireHook( 'wikibase.statement.savedWithContext', self._entity, statement );
				
				//Step 2: Use ^^ in QualityConstraints
				
				//Step 3: Delete this vv
				self._fireHook( 'wikibase.statement.saved', self._entity.getId(), guid );
				
				//Step 4: update self._entity with new content: new code here :)

This means keeping this part of statement saving basically the same. We'll still be using this old-ish (but obviously working) code for saving changes to statements.

We're wondering if we really ought to be using this moment of touching statement saving to update how things are done. We're wondering if anyone (maybe @Lucas_Werkmeister_WMDE or @Jakob_WMDE or @Pablo-WMDE?) thinks we should be using this to do some more architectural refactoring of this bit of the front end.

I think this is buried so deeply in the legacy JS code that refactoring it would be hard. But it would be great to hear if other people see some obvious chunk that we could isolate and move to a more modern JS style.

We are imagining perhaps altering StatementChanger.js with something like

If you need more data in the hook, you can just add extra arguments to it without making an incompatible change (or am I misunderstanding something?).

If you need more data in the hook, you can just add extra arguments to it without making an incompatible change (or am I misunderstanding something?).

You're not misunderstanding: we could definitely do that. It might well be better to add as additional optional parameters the old and new statements.

WMDE-leszek closed this task as Resolved.Sep 23 2019, 11:16 AM
WMDE-leszek claimed this task.