Simplify field saving before draft publishing.
Review Request #13043 — Created May 11, 2023 and submitted — Latest diff uploaded
In order to make the "save before publish" operation a little more
streamlined, I'm rearranging things so that it can be somewhat less
event driven. This previously involved:
ReviewRequestEditorView
callsfinishSave
for each open field.- The field calls
InlineEditorView.submit
.InlineEditorView.save
triggers the "complete" event.- "complete" is handled by the field view, which calls
ReviewRequestEditor.setDraftField
ReviewRequestEditor.setDraftField
callsReviewRequestDraft.save
with the new data.- As each of the fields are saved,
ReviewRequestEditor
is keeping
track via apendingSaveCount
attribute, which will trigger a new
call topublishDraft
once the count is zero.After this change, it involves:
ReviewRequestEditorView
callsfinishSave
for each open field,
using the returned promise to wait for the save completion.ReviewRequestEditorView
callsReviewRequestEditor.publishDraft
.IMPORTANT NOTE: this only affects the legacy draft review banner, which
is disabled and will be removed soon (perhaps before RB6, perhaps
after). A similar implementation for the unified banner is coming next.This change also fixes up several unit tests which had been broken by
refactoring but were marked as "pending" when the unified banner is
enabled.
- Ran js-tests.
- Disabled the unified banner feature and ran js-tests.
- Disabled the unified banner feature and published a draft while
several field editors were open. Saw them all save and the draft
publish correctly.