You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Formalize the "pushChanges" method as supported, by documenting it, so users can implement this type of experience
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!
The text was updated successfully, but these errors were encountered:
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:
Let me know if you need more context, and thanks in advance!
The text was updated successfully, but these errors were encountered: