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

Track Changes as a Collaborative Editor #4855

Open
ravemir opened this issue Dec 10, 2024 · 0 comments
Open

Track Changes as a Collaborative Editor #4855

ravemir opened this issue Dec 10, 2024 · 0 comments

Comments

@ravemir
Copy link

ravemir commented Dec 10, 2024

Hello,

I reached out to support recently about the behavior of the built-in plugin Track Changes, which we believed could be used to implement a use case on our app, but ultimately were only able to while using an undocumented method. More context below.

Intended Use-case

Implement a document review screen, where reviewers could suggest changes to the document inline to the current content. The reviewer would simply add, remove or change text in the original document, while viewing these changes marked explicitly (e.g. as text with a red/green colored background). Once all suggestions are done, the reviewer would save them and end his interaction.

At another point in time, the creator of the original document would access the screen and load the suggestions from the reviewer into his editor, manually pick out which to accept or reject. It would be desirable to note which suggestions were accepted or rejected, but the essential part is that the suggestions were presented to the creator, and eventually added or not into the final document.

Our Attempt to Implement this with the Froala Editor

We tried using the Track Changes feature to achieve this: first, we implemented the reviewer screen by automatically enabling the tracking of changes, and then saving the content of the document once the user is done. We realized that at this point, the original HTML content was edited with references to these suggestions, hinting we could load this content for the producer and automatically have the suggestions made available.

However, once we did that, we realized that only the styling of the suggestions (i.e. colored backgrounds) was available: calling any of the JavaScript methods of the plugin (e.g. getPendingChanges, acceptAllChanges) acted as if there were no changes tracked at all. It's almost as if the editor not only changed the HTML content when tracking changes, but also had some form of internal state tracking them as they were added.

Eventually, we discovered the plugin method "pushChanges" (and "popChanges" along with it), which allowed us to manually re-add these changes by their original Id (which we could find in the HTML content with the tracked changes).

Suggested Change/New Feature

It felt natural that the original Track Changes plugin would be used in the manner we intended, that is, to track changes done by one user and then allow a second user to accept/reject them, resulting in a collaborative experience. This is the case with the Suggesting mode of Google Docs, for example.

As such, we propose that the plugin is changed in one of the two ways:

  1. Formalize the "pushChanges" method as supported, by documenting it, so users can implement this type of experience
  2. Automatically push changes detected in the content of the editor on the first load

Let me know if you need more context, and thanks in advance!

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

No branches or pull requests

1 participant