Generate edit payload in save effect handler #1062
Conversation
| } | ||
|
|
||
| export function savePost( postId, edits ) { | ||
| export function savePost() { |
There was a problem hiding this comment.
We may want to provide a way to explicitly pass the edits we want to persist. I'm wondering if the "Revert to draft" button should save all the current edits or only the status (could be resolved in the "Revert to draft" PR)
There was a problem hiding this comment.
An interesting question. Another question is whether we want the "Revert to draft" action to immediately request the update, or wait until an explicit Save/Update action. The latter is the behavior of the current editor, but per the mockup shown at #945 (comment) , the expectation with a button might be more that it would take effect immediately.
There was a problem hiding this comment.
In any case, yes, let's defer this to the "Revert to draft" changes.
Related: #945 (comment)
This pull request seeks to defer save payload to be generated during the save effect handler, instead of making it the responsibility of each saving component to construct. Instead, the component can merely call
savePost. There's a bit of uncomfortable magic in allowing the effect handler to make heavy use of the current state, but arguably outweighed by the usability benefit. I'd still like to consider further splitting theREQUEST_POST_UPDATEhandler, e.g. standalone handlers for the actual network request, clearing edits.Testing instructions:
Ensure unit tests pass:
(Will need to revisit #966 with updated effect tests)
Verify that there are no regressions in: saving, publishing, privately published, or changing status of an existing or new post and updating / saving said post.