pedrosanta / quill-sharedb-cursors Goto Github PK

A known issue of this approach/example is a racing condition which makes cursors stuck/out-of-correct-position sometimes when a selection-change cursor update (which goes through cursors socket) is quickly followed by some edits (which goes through ShareDB and its socket) - like using the back arrow key with Ctrl to go to the beginning of a word and immediately start typing.

How to replicate:

1. Open two side-by-side windows on https://quill-sharedb-cursors.herokuapp.com;
2. On one of them try to move to the beginning of a word with the keyboard shortcut (Ctrl/Option+Left Arrow) and inserting some text immediately after;
3. If you do these things quick enough, the cursor on the other client might become off-position.

My take is that:

• Sometimes, the insert operation gets processed first (and vice-versa) on server (which moves cursor forward) and then the message with absolute position (from the arrow caret move) comes in and places the cursor behind from it is on the other client;
• Sometimes the cursor doesn't even move from the place of start, meaning that it only gets updated/shifted on the insert operations, like the server hasn't ever received the caret change update/message in the first place;

One solution for this was if... cursor updates could be transmitted through ShareDB (probably as ephemeral metadata like stated on share/sharedb#128).

Still needs more testing.

Great project!

The install instructions mention Docker, but the demo is deployed on Heroku. Is there a guide available on how to deploy this to Heroku?

Hi, I think it is not directly related to this module, but any idea how do you handle the following problem with IME keyboards (extra english words).

Sometimes, when two or more users are typing and adding new lines/pressing Enter key, it can lead to cursor misplacement/shift off by one, two, etc, positions.

You can replicate this by having two people on this example, one writing forward without entering new lines, and another writing and adding a few new lines. This doesn't occur on the first new line attempts, but after a solid half-dozen or more new lines/enter keypresses by the second person.

Also needs more testing/debugging.

I noticed that if User1 highlights an area and User2 tries to click in the highlighted are they are not able to. However, if User2 uses the arrow keys they can enter the highlighted text area. Is this desirable or not? If User2 types in the highlighted text-area the amount of spaces highlighted remains the same but the original highlighted text is modified and now includes the additional characters.
See Ex:
[this is highlighted] -> brackets mean highlighted text
User 1: hi my country is [great] (User1 highlight)
User 2: hi my country is [not g]reat (User2 modifiying highlighted text changes the highlighted portion)

@pedrosanta hey, and thank you for the wonderful work so far with sharedb and quill!

I was able to follow along and get quill and sharedb working with my application.

But I have multiple quill documents on a page. And each document generates its own quill instance with cursor module.

So each quill instance registers its text change event with the syncing of the cursors.

So when editing a particular note, it sets the range of that note, but the range is applied to every note.

I think it would be good to come up with a solution where it doesn't require only one quill document on a page.

We need someway to scope the cursor to the particular quill instance.