Запретить ckeditor запускать обратный вызов, когда текст обновляется внешним источником - PullRequest
4 голосов
/ 22 января 2020

Я работаю над проектом Vue в реальном времени, который использует ckeditor5 в качестве текстового редактора. Pusher - это API в реальном времени, который использует websocket для трансляции событий в другие экземпляры Pusher в реальном времени. Это Pusher

В конфигурации ckeditor я передаю обратный вызов set. Этот установленный обратный вызов запускает любое изменение текста, и я использую его для запуска событий толкателя, передавая текстовое значение другим экземплярам толкателя.

Проблема возникает, когда другой экземпляр толкателя на их стороне получает событие, и после его обработки Vue реактивно обновляет текстовое значение в DOM, вызывая тем самым вышеупомянутый обратный вызов set, который снова вызывает событие. В среде реального времени он портит обновление значения и заканчивается мерцанием текста.

В обратном вызове я получаю только строковое значение и не могу выяснить, что инициировало обратный вызов, поэтому могу ' t остановить выполнение.

Есть ли способ запретить ckeditor5 запускать обратный вызов?

Это может быть проблемой, существующей в каждом проекте на основе веб-сокетов.

1 Ответ

1 голос
/ 17 февраля 2020

Проблема заключается в том, что когда изменение запускает широковещательную рассылку, а клиент Pusher получает и применяет ее, то она становится широковещательной при изменении клиентов. Когда исходный вещатель получает изменение, он не может определить, является ли это его собственным изменением, и применяет его снова.

После нескольких неудачных попыток создать плагин ckeditor, который отфильтровывает входящие изменения, которые были инициализированы. Для самого экземпляра ckeditor я решил обойти эту проблему.

Я создал кеш, который перед трансляцией инициализированных изменений сохраняет их в течение нескольких секунд. Когда изменение получено от клиента Pusher, изменение применяется только в том случае, если оно отсутствует в кэше, поэтому оно инициализируется другим клиентом.

Этот обходной путь работает в большинстве случаев, но могут быть проблемы с очень медленным inte rnet соединением с низким временем отклика (зависит от времени кэширования).

...