@marcel Two major points from my perspective:
-
For decoration approach, there is clear separation of non-editable document with ability to comment in “read only” mode. The document can be locked / non-editable yet users with view access can still comment via adding start/to range in a separate data structure than the main document object. It can be an entirely separate field in a database for instance, managed/updated via dedicated endpoint with different authorization. The same is possible via mark approach if you have a centralized collab server and assert on transaction metadata, but this is again, more complicated and some don’t have a centralized collab server. If you don’t have a centralized collab server, you’ll probably (shouldn’t trust only client) need to diff the entire document JSON to ensure a user isn’t editing a document in non-authorized ways. That is, document edits other than just appending comment marks to blocks.
-
The data structure for decoration comments are a more straightforward model defined solely by a single from/to. The mark approach will mark each discrete block that is contained in the user’s selection and add each to the doc JSON. So there may be more than one persisted mark for each comment which may have a solution to manage, but it’s not as easy to tame as one may think? The decoration solution will eventually produce DOM with multiple comment wrapper blocks (if necessary,) but they are a view concern rather than something that is persisted into a data model (And prosemirror handles all of that automatically via the decoration implementation DOM output)
That being said, decoration solution undo/redo indeed is difficult and I don’t have a working solution for that yet. But I eventually need to implement something of the sort.