Gutenberg: Сравните разные технические подходы

Созданный на 23 февр. 2017 · 3Комментарии · Источник: WordPress/gutenberg

Пока что у нас есть эти технические прототипы:

1- https://wordpress.github.io/gutenberg/tinymce-per-block/

Multi-TinyMCE
Контролируется (состояние -> рендеринг -> событие -> состояние -> повторный рендеринг)
Состояние представлено как объект
Использование грамматики

2- https://wordpress.github.io/gutenberg/tinymce-single/ (одиночный TinyMCE, неконтролируемый, без грамматики, парсинг HTML)

Единый глобальный TinyMCE
Неконтролируемый (состояние -> рендеринг -> событие -> newState)
Состояние - это простая строка, содержащая весь HTML.
Грамматика не используется внутри редактора, но мы можем добавить грамматические комментарии при вызове tinymce.getContent

(Не стесняйтесь добавлять сюда любой другой технический прототип)

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

[Type] Question

Источник

youknowriad

Самый полезный комментарий

Вот мои впечатления об этих двух прототипах:

Прототип 1:

Плюсы:

Кажется, проще использовать блоки вне контекста редактора
У меня есть личные предпочтения по сравнению с состоянием в качестве объекта, внешнее манипулирование состоянием (действия, не встроенные в TinyMCE) кажется более простым.

Минусы:

Многоблочного выбора добиться невозможно. Ctrl + A для каждого блока.

Prototype 2:

Плюсы:

Многоблочный выбор
Легче добиться ощущения полнотекстового интерфейса

Минусы

Сложнее повторно использовать блоки вне редактора?
TinyMCE может переопределить некоторое поведение по умолчанию внутри содержимого блока https://wordpress.slack.com/archives/core-tinymce/p1487169326000067

На основе этого экспериментального прототипа https://github.com/WordPress/gutenberg/pull/113 я попытался использовать смешанный подход, в котором мы используем TinyMCE в качестве оболочки, но повторно отображаем его содержимое на основе изменений состояния. После некоторого исследования этот подход похож на попытку воссоздать DraftJS или ProseMirror. И я не думаю, что это правильный способ использовать TinyMCE.

youknowriad 23 февр. 2017

❤3

Все 3 Комментарий

Вот мои впечатления об этих двух прототипах:

Прототип 1:

Плюсы:

Кажется, проще использовать блоки вне контекста редактора
У меня есть личные предпочтения по сравнению с состоянием в качестве объекта, внешнее манипулирование состоянием (действия, не встроенные в TinyMCE) кажется более простым.

Минусы:

Многоблочного выбора добиться невозможно. Ctrl + A для каждого блока.

Prototype 2:

Плюсы:

Многоблочный выбор
Легче добиться ощущения полнотекстового интерфейса

Минусы

Сложнее повторно использовать блоки вне редактора?
TinyMCE может переопределить некоторое поведение по умолчанию внутри содержимого блока https://wordpress.slack.com/archives/core-tinymce/p1487169326000067

youknowriad 23 февр. 2017

❤3

Спасибо за создание этого билета.

При сравнении нам также следует подумать о № 3, поскольку это, кажется, зависит от того, какой подход мы выберем.

jasmussen 23 февр. 2017

Я думаю, что Prototype 2 - это правильный путь, хотя это может быть больше проблем, потому что он потребует намного больше работы TinyMCE, в конечном итоге это, вероятно, будет лучшим подходом на данный момент.

Сложнее повторно использовать блоки вне редактора?

Я думаю, что это не будет недостатком для Prototype 2, если API для определения типов блоков и типов управления предоставляет достаточно данных для использования чего-то другого, кроме TinyMCE. Я думаю, нам следует разработать API для определения типа блока / типа управления, который будет использоваться для загрузки сильно настраиваемого экземпляра TinyMCE. Данные из типа блока / типа управления также могут быть использованы для питания чего-то еще в будущем.

Несмотря на то, что это, вероятно, неприятно, Prototype 2 отражает большую часть того, как уже работает WordPress, и TinyMCE многое делает, что для меня делает его очень разумным путем вперед.