@itgenio/edik-sync

Sync

Обсуждение синхронизации состояния материала между пользователями.

Дополнительно, возможно, можно использовать для синхронизации состояния внутри сессии.

Инициализация

Пользователи запрашивают последнее состояние. Дальше применяют команды.

• команды можно применять только к общему состоянию, чтобы не было рассинхрона.

Команды

Команда - это действие, которое необходимо совершить над материалом.

На основе команд можно сделать:

• проигрыватель действий пользователя
• буфер действий(cmd+z)

Идея Server Side Model

Так как материал - сложное состояние с циклическими ссылками, логикой и т.д., сложно обновлять состояние дифами через запросы в бд:

• команда "Обновить поле"/"Удалить компонент" и пр. может затрагивать большое число точечных изменений.
• т.к. возможны real-time механики, число команд в секунду может быть большим.
• необязательно сохранять изменения в бд мгновенно, можно подождать 1-2 сек.

Решение - запуск живую копию материала на сервере и менять ее через команды, параллельно синхронизируя ее между всеми сессиями.

Копия должна запускаться только на одном сервере, чтобы гарантировать целостность.

В базу можно сохранять команды, а не изменения.

При публикации обязательно мержить команды и состояние в конечное состояние.

Совместное редактирование материала

• необходимость в истории действий с возможностью откатить
• скорость и размер не так важен

Вариант решения: base + cmd1 + cmd2 + ...

Совместное использование материала

• нельзя откатить(нет истории действий)
• скорость и размер важны

Список команд

Slide

createSlide

{
  "id": String,
  "index": Number
}

removeSlide

{
  "id": String
}

moveSlide

{
  "id": String,
  "index": Number
}

SlideObject

createObject

{
  "id": String,
  "slideId": String,
  "index": Number
  //...otherFields
}

removeObject

{
  "id": String
}

moveObject

{
  "id": String,
  "index": Number
}

changeParent

//TODO совместить с changeObjectField?

{
  "id": String,
  "newParentId": Optional<String>,
  "newIndex": Optional<Number>,
}

changeObjectField

type ValueType = 'string' | 'number' | 'objLink' | 'compLink';

{
  "id": String,
  "field": String,
  "data": {
    "type": ValueType,
    "val": any
  }
}

Примечание: data может быть как примитив, так и ссылка на компонент/объект.

createComponent

{
  "id": String,
  "type": String
  //...otherFields
}

removeComponent

{
  "id": String
}

changeComponentField

{
  "id": String,
  "field": String,
  "data": {
    "type": ValueType,
    "val": any
  }
}

Примеры

Создание готового объекта (сложная структура)

Надо отсылать сразу готовый объект вместе с компонентами, чтобы не спамить командами.

Копирование объекта

Аналогично пункту выше, сразу готовый объект

Удаление слайда

Влечёт за собой удаление всей внутренней структуры

Удаление объекта

Влечёт за собой удаление всей внутренней структуры.

При этом нужно очищать ссылки, что влечёт за собой изменение полей в каких-то компонентах.

Несколько вариантов решения:

шлём команду на удаление, локально изменяем модель

Каждая локальная копия сама очистит ссылки и удалит объекты.

• надёжнее, так как точно удалится объект со всей иерархией;
• меньше данных гоняем по сети;
• больше вычислений: чтобы удалить объект, нужно распарсить всю иерархию;

шлём команду + список изменений, локально применяем

Каждая локальная копия применит только те изменения, которые просчитал инициатор.

Тут может возникнуть ситуация, когда мы что-то начали делать внутри удаляемого объекта и пришла команда Удалить, и наши изменения не будут в списке изменений инициатора.

• возможен рассинхрон
• больше данных по сети

Вопросы

Буфер действий = буфер команд?

Нет, так как буфер действий привязан к интерфейсу редактора, в то время как буфер команд отражает изменение модели материала.

Как будет работать компиляция и регистрация кастомных типов

TBD