Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display Saving label while save in progress #1301

Merged
merged 2 commits into from
Jun 20, 2017
Merged

Display Saving label while save in progress #1301

merged 2 commits into from
Jun 20, 2017

Conversation

aduth
Copy link
Member

@aduth aduth commented Jun 20, 2017

Closes #707
Related: #1203

This pull request seeks to resolve a regression introduced in #1203 where the "Saving" label is no longer shown in the header while a save is in progress. The issue is due to the fact that when a save begins, post edits are cleared, meaning that the post is considered un-saveable (no title, content, or excerpt). Due to the order of logic in SavedState, this resulted in nothing been shown, instead of the "Saving" label, despite a save being in progress.

Implementation notes:

Should we really be clearing post edits when a save is initiated? My thinking is that we should optimistically persist them as being the current state of the post. cc @youknowriad

Testing instructions:

Verify that a Saving label is shown after clicking Save in the editor bar, while the request is in progress. Using Chrome Developer Tools network throttling to emulate a slower connection can help identify the change in label.

@aduth aduth added the General Interface Parts of the UI which don't fall neatly under other labels. label Jun 20, 2017
@youknowriad
Copy link
Contributor

Should we really be clearing post edits when a save is initiated? My thinking is that we should optimistically persist them as being the current state of the post. cc @youknowriad

I don't understand, that's exactly what we're doing.

@aduth aduth mentioned this pull request Jun 20, 2017
Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and approved :)

And thanks for the unit tests

@aduth
Copy link
Member Author

aduth commented Jun 20, 2017

I don't understand, that's exactly what we're doing.

Right, my question could have been phrased better. I mean to suggest maybe we shouldn't be doing this.

@youknowriad
Copy link
Contributor

@aduth We're doing so to avoid mixing the persisted edits with the edits added during the save. Diffing could be an alternative.

@aduth
Copy link
Member Author

aduth commented Jun 20, 2017

avoid mixing the persisted edits with the edits added during the save

Why do we need to avoid it? Isn't this why we include redux-optimist, so we can revert if we need to?

@aduth aduth merged commit 606c0fc into master Jun 20, 2017
@aduth aduth deleted the fix/707-saving branch June 20, 2017 12:45
@youknowriad
Copy link
Contributor

@aduth but that's not about reverting. I'm having a hard time understanding what you mean exactly. We clear the edits before saving, that way new edits are added even if we didn't get the response yet and we're. So we're already optimistically clearing edits and moving them to the currentPost.

@aduth
Copy link
Member Author

aduth commented Jun 20, 2017

Okay, you've reminded me of the fact we need to preserve edits made while the save is in-flight. That makes sense now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

UI: Separate out drafting, saving, publishing actions
2 participants