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

Clean up frontend change tracker and snackbars related to undoing operations #3480

Merged
merged 3 commits into from
Aug 15, 2022

Conversation

bjester
Copy link
Member

@bjester bjester commented Aug 3, 2022

Summary

Description of the change(s) you made

  • Removes the troubled change-locking implementation of the frontend change tracker used for reverting changes
  • Resolves some issues with snackbars related to copying and moving nodes, and clipboard operations too, to ensure that the snackbars display

Manual verification steps performed

  1. Duplicating a node and undo it
  2. Copying a node to the clipboard
  3. Moving a node
  4. Delete a node and undo it

References

Comments


Contributor's Checklist

PR process:

  • If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
  • If this includes an internal dependency change, a link to the diff is provided
  • The docs label has been added if this introduces a change that needs to be updated in the user docs?
  • If any Python requirements have changed, the updated requirements.txt files also included in this PR
  • Opportunities for using Google Analytics here are noted
  • Migrations are safe for a large db

Studio-specifc:

  • All user-facing strings are translated properly
  • The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
  • All UI components are LTR and RTL compliant
  • Views are organized into pages, components, and layouts directories as described in the docs
  • Users' storage used is recalculated properly on any changes to main tree files
  • If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

  • Code is clean and well-commented
  • Contributor has fully tested the PR manually
  • If there are any front-end changes, before/after screenshots are included
  • Critical user journeys are covered by Gherkin stories
  • Any new interactions have been added to the QA Sheet
  • Critical and brittle code paths are covered by unit tests

Reviewer's Checklist

This section is for reviewers to fill out.

  • Automated test coverage is satisfactory
  • PR is fully functional
  • PR has been tested for accessibility regressions
  • External dependency files were updated if necessary (yarn and pip)
  • Documentation is updated
  • Contributor is in AUTHORS.md

}
});
});
}
Copy link
Member Author

@bjester bjester Aug 3, 2022

Choose a reason for hiding this comment

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

@rtibbles Interested in your thoughts on this use of liveQuery. I added this to detect when copying is finished so we can show the snackbars appropriately.

@bjester bjester marked this pull request as ready for review August 5, 2022 21:18
Copy link
Member

@rtibbles rtibbles left a comment

Choose a reason for hiding this comment

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

This looks like good cleanup - one comment about possible future directions for undoing, but I don't think it affects the code as is. Will manually test.

return promiseChunk(this._changes.reverse(), 1, ([change]) => {
const table = db[change.table];
return db.transaction('rw', change.table, () => {
// This source inherits from `IGNORED_SOURCE` so this will be ignored
Copy link
Member

Choose a reason for hiding this comment

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

Thinking about the future, if we are immediately sending changes to the backend using websockets, maybe we should be emitting 'reversions' as full changes that also get propagated to the backend, rather than trying to catch them before they're applied?

More like git reverting a commit, rather than dropping a commit. The main challenge comes for things like publishing and syncing where there is not a clear path for what a 'restore' looks like.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is a great catch because by removing the change locks, I did change the behavior to be more like a git revert, but I did not update this logic accordingly! This logic should no longer use an ignored source for the updates. At the moment, we're only wrapping copy and move operations, so events like publishing and syncing shouldn't even occur here, but it would be good to be defensive against those things.

.toArray();
});

return new Promise((resolve, reject) => {
Copy link
Member

Choose a reason for hiding this comment

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

I think your comment got lost in a rebase, but this does look like a neat way to watch for changes.

@bjester bjester requested a review from rtibbles August 11, 2022 16:30
Copy link
Member

@rtibbles rtibbles left a comment

Choose a reason for hiding this comment

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

Code review looks good, manual testing shows no errors, and I am seeing snackbars!

if (this._isBlocking) {
this._isBlocking = false;
this.emit('unblocked');
doRevert() {
Copy link
Member

Choose a reason for hiding this comment

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

I think this logic could also be useful for handling changes that error on the backend too (but in that case I suppose it would be an ignored change).

@rtibbles rtibbles merged commit a34942d into learningequality:unstable Aug 15, 2022
@pcenov
Copy link
Member

pcenov commented Sep 27, 2022

  1. Sometimes I am getting an "Unable to revert changes without tracking some changes" error in the console when I attempt to Undo a deleted resource but this is not always reproducible.

2022-09-27_15-49-45

  1. As reported in Hotifxes - Undoing a move operation does not revert the change in the backend #3680 if I delete a resource and restore it and then sign out when I sign in again and go to the channel the resource is not displayed in the Editor, only in the Trash.

  2. Not sure if this is caused by changes made here but I also noticed that again sometimes after performing Undo, the Delete option ceases to function:

2022-09-27_16-12-39.mp4

cc @radinamatic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants