Autosave drafts after delay #1945
Conversation
|
Autosave is also closely related to the need to previewing changes on the frontend: #1673. |
mtias
added
the
[Type] Task
| REPLACE_BLOCKS: () => queueAutosave(), | ||
| REMOVE_BLOCKS: () => queueAutosave(), | ||
| EDIT_POST: () => queueAutosave(), | ||
| MARK_DIRTY: () => queueAutosave(), |
There was a problem hiding this comment.
Why do we need all these effects? I suspect dirtiness? Can't we use an internal somewhere instead?
There was a problem hiding this comment.
Why do we need all these effects? I suspect dirtiness? Can't we use an internal somewhere instead?
Yeah, all the potentially dirty-ing effects, see also: reducer for editor.dirty.
As remarked in #1967, I'd like to look to reimplementing dirtiness as a diff against the original saved post, in which case we could reimplement this as a subscribe on the store (i.e. if ( currentDirty !== lastDirty ) queueAutosave()).
editor/selectors.js
Outdated
| * @param {Object} state Global application state | ||
| * @return {Boolearn} Whether the post has been bublished | ||
| */ | ||
| export function isEditedPostPublished( state ) { |
There was a problem hiding this comment.
I'm having trouble understanding if this is really necessary because the status is changed to 'publish', 'private' only when saving. so no real difference with isCurrentPostPublished. Btw, good renaming.
There was a problem hiding this comment.
If I recall correctly, the issue is that if the user chooses a date in the past for their draft post, the edited representation of the post becomes "published", but we can't necessarily use the published autosave flow because the saved post is still a draft.
... I think there's still something amiss here though, because in the AUTOSAVE effect above I'm still testing against the edited version of the post, not the "current" (saved) copy.
editor/effects.js
Outdated
| } | ||
|
|
||
| if ( isEditedPostPublished( state ) ) { | ||
| // TODO: Publish autosave |
There was a problem hiding this comment.
What's the desired behaviour here?
There was a problem hiding this comment.
What's the desired behaviour here?
Published posts have a distinct auto-save behavior which is not currently possible to implement due to lacking API support: #1773 (comment)
|
I'm trying to sort through what should be the autosave behavior, particularly around transitioning status. The obvious ones are draft staying draft, and published staying published, but it becomes less clear when the post status is modified in the same session:
|
Do you know how does Calypso resolve this? |
|
In general, the changes of status in Calypso performs the action. That's why we have "revert to draft" as a button, to try to keep it binary. @jasmussen we should look again at the status area from the point of view of published/draft. Related: #1726 |
"edited post" in context of selectors should refer to current post + edited values. Current usage tests against saved post only. Needed to distinguish for "isEditedPostPublished" testing current post with edited values applied.
aduth
force-pushed
the
update/1773-autosave-draft
branch
from
1a47c9d to
56d6dfa
Compare
|
Rebased and force-pushed with some new tests. Also updated the condition for handling published autosaves to checking the current (last saved) post in deciding whether to abort. When auto-saving a post which had originally been published, we may need some additional logic, but this can be implemented separately. In the meantime I've included some thoughts as inline comments. I'd have liked to have been more strict with how autosave behaves depending on the actual data of the edited post. For example, while not possible by user flows, if a draft is applied an unsaved edit of |
…-android [Android] Add logging to Page Template Picker
Partial resolution for #1773
This pull request seeks to implement an incomplete autosave behavior, currently applied to drafts only. Published posts lack API endpoint requirements for creating autosaves (see #1773 (comment)) and will need to be implemented separately. Further improvements may be needed for handling autosave for private or scheduled posts, currently ignored as of these changes.
Implementation notes:
Autosave occurs on a 10 second debounce. The current post editor hooks to heartbeat lock refresh to trigger an autosave. More consideration may be needed for autosave frequency and use of browser storage for locally saved copies of the post. Discussion may be better reserved for #1773, though this pull request seeks to start exploring a minimal solution.
Testing instructions:
Verify that autosave occurs for a draft 10 seconds after a change: