search

yabwe / medium-editor

Medium.com WYSIWYG editor clone. Uses contenteditable API to implement a rich text solution.
https://yabwe.github.io/medium-editor/
Other
16.03k stars 1.85k forks source link

Realtime collaborative editing possible? #1002

Open tyler-johnson opened 8 years ago

tyler-johnson commented 8 years ago

I am currently doing some research into various web-based WYSIWYGs and so far I really like MediumEditor since it seems to be easy to customize for our needs.

One of our requirements is realtime collaborative editing, something similar to Google Docs. I realize that there is probably no out-of-box support for this like quilljs has, but is this doable in MediumEditor through extensions?

Mostly by collaborative, I mean:

nmielnik commented 8 years ago

Collaborative editing is definitely an interesting problem to try to solve with medium-editor. I'm not aware of anyone who's been using the editor in this fashion, but it's possible others have done it.

A couple of things that come to mind:

  1. There isn't multiple cursor support. If you wanted to show the cursor of other collaborators, you'd have to have some sort of custom method to 'draw' a cursor on the screen. Perhaps via a psuedo-element?
  2. Currently, the contents of the editor are simply html and don't have a backing data model. I'm not sure how to resolve editing conflicts with html. If you went with a transaction-like approach (where each user's text changes are represented via a transaction) this might be easier, but it'd take some custom code to do this.
  3. There is some good support for saving and restoring selection in medium-editor, so it should be possible to handle some of the trickiness with that.
  4. Different browsers create different html, which can make things problematic. For example, firefox and chrome handle text alignment differently. One uses the align attribute, another users text-align css property. Thus, there can be cases where the style of the markup produced by one browser can't be undone by the other.
  5. What should undo/redo behavior be? If you're modifying the html of the editor based on external changes, you will likely have to disable the browser's built-in undo/redo, depending on what the expected behavior is.

Not sure how much this helps, but figured I'd share some of my thoughts.

tyler-johnson commented 8 years ago

Thank you for the response! What I like about this answer is that it is not a flat out no, which is what I was hoping for. We are definitely willing to put in some extra work to get this going, so I don't mind a daunting task. Some of the items mentioned (like custom undo/redo) we need for other items anyway, so I think this is very doable for us. I will certainly attempt to open source whatever solution we come up.

As far as this issue goes, it is closed on my end but I'll leave it open in case you desire to leave it in the open issues.

Thanks so much!

rvetere commented 8 years ago

As already stated.. this is really not easy.. :) but extremely interesting indeed! The concerns mentioned by @nmielnik are absolutely there and.. tough..

What feels funny to me, i'm actually fidling around with meteor1.3 and angular2 and i already got a prototype now which is almost there - bringing me a collaborative editing.

This is because meteor is using a DDP rather than classical HTTP and he will push everything to everybody connected, completely bidirectional, completely behind the curtains - you don't write 1 line of code to get this work, it is just there.. super magical awesome!

But ok.. i get this running to the point where my json model is laying - from there, the missing last piece.. the virtual cursors of the others, handling conflicts.. handling undo/redo.. this is the thing that is really tough to get but it is really easy nowadays to get this "connected client architecture" which is even harder to build that first if you don't have it.

If you won't go with meteor.. have a look into express apps with firebase integration -> firebase will bring you to the same state of connectivity like meteor - and i think it's an awesome starting point to work with such a solution/experiment...

I would love to make some progress in this fields in the future :)

what if an editor would stop producing html.. i mean... catch aaaall the basic keystrokes.. generate an abstracted json format with the key inputs first and let it simply "parse" in the end to html.. this way we could intercept the undo/redo on a much nicer json level instead of html.. and the json produced of all the browsers would still be the same, because our code is generating it, not any fucked up browser implementation.. then there is a neat jsondiffpatch lib which could handle diffs and patches of pure json extremely well, which could be a life-safer for undo/redo basically... haha, funny thoughts... i'm afraid this is the pain-in-the-ass job the medium.com dev's are going trough.. at least the thing with "catch all the keystrokes, and fix everything behind it on your own"

olehmelnyk commented 8 years ago

I'm also interested in real-time collaborative editing! Have you ever heard of Google Realtime API Is that something that can help to implement real-time editing?

nmielnik commented 8 years ago

Google Realtime API looks great, it sounds like we'd need a JSON data model for it to help us though (see #434)...but if we ever get that, this API sounds perfect.