Спасибо за комментарий. Я не совсем понял про использование реакт компонентов в контенте. Вы про использование их в момент использования редактора, или про саму контентную страницу? С контентными страницами кажется всё довольно простым: мы итерируем элементы в массиве данных и вольны выбирать как их отрисовывать, как компонент или как строку. В самом редакторе мы Vue компоненты ещё пока не использовали, но, скорее всего, будем это делать как и эмбеды. У proseMirror в схеме написано, что нужно вставить вот такой с такими дата-аттрибутами и потом вызвать вот эту функцию. В функции можно выбросить событие или воспользоваться заранее прокинутым API с react. Так как proseMirror уже не сильно важно, что происходит внутри atom ноды, там может происходить что угодно. Но это простой вариант, в котором односторонняя связь proseMirror->что-нибудь. Если из компонентов нужно иметь воздействие на контент то уже не подойдёт. Для двусторонней придется попотеть с плагином, его я уже так быстро не опишу, но и супер-сложного там нет.
Почему формат proseMirror не удобен? На это я не смогу ответить. Основная проблема, что формат хранения был у нас уже до выбора решения для визивига. Предполагалось, что мы возьмём визивиг, который будет в нашем формате данные брать:) Оказалось, что таких нет, а клиенты уже пользуются нашим форматом.
Почему Вы решаете за нас, какие сообщения для дева, а какие нет? Разве мы не можем пользоваться этими сообщениями на проде? Например кто-то видит поведение, которое считает неправильным, мы просим показать консоль, а потом объясняем, что так и должно быть и почему или фиксим.
Мы, разумеется, сначала накидали примерную схему sb, которая отвечала бы нашим требованиям, и искали что-то подобное, может недостаточно тщательно.
Обсудить и реализовать формат было довольно быстро. Основная работа с форматом была в специфике проекта. Различные эмбеды, обязательные поля, требования к данным разных клиентов. Это было бы в одном объеме сделано вне зависимости от стартового формата, так что ничего страшного не произошло.
И это немного не про визивиг. Когда мы пришли к непосредственной разработке его у нас не стоял выбор формата уже.
Нет. Мы рассматривали только описанные выше 3, из-за хранения в json. Конвертация html>sb довольно непростой процесс, жить с которым постоянно было бы больно.
В целом, мы и взяли готовый фреймворк для визивига. Без proseMirror разработка бы не была обоснована совсем. Я уверен, что с trix мы бы решали несколько больше проблем, чем с proseMirror.
Tiny в таком случае не гарантирует консистентности. У нас точно будут потери на этапе html>sb, а значит это уже не wysiwyg. Структура, которую он выдает, не очень похожа на плоское представление информации. Плюс есть достаточное количество абсолютно лишних тэгов, которые он вставляет, особенно при копипасте из гугл-доков. Ну и к этому всему в tiny нельзя поставить каких-то жестких рамок ни по структуре данных, ни по представлению определенных типов.
Например: картинка с подписью. В tiny мы либо пишем плагин который будет работать с картинками именно так, как нам нужно(и я не уверен, что получится в полной мере), либо редактор (блогер) будет каждый раз сам придумывать, как ему сделать эту подпись(в каждом материале будет не по дизайну).
Дело вообще не в Tiny, дело в формате данных. Главная задача была «не хранить HTML». Нужна была довольно плоская структура, удобная для всех клиентов и бэка в виде JSON.
У proseMirror в схеме написано, что нужно вставить вот такой
<div>с такими дата-аттрибутами и потом вызвать вот эту функциюСпасибо за комментарий. Я не совсем понял про использование реакт компонентов в контенте. Вы про использование их в момент использования редактора, или про саму контентную страницу? С контентными страницами кажется всё довольно простым: мы итерируем элементы в массиве данных и вольны выбирать как их отрисовывать, как компонент или как строку. В самом редакторе мы Vue компоненты ещё пока не использовали, но, скорее всего, будем это делать как и эмбеды. У proseMirror в схеме написано, что нужно вставить вот такой с такими дата-аттрибутами и потом вызвать вот эту функцию. В функции можно выбросить событие или воспользоваться заранее прокинутым API с react. Так как proseMirror уже не сильно важно, что происходит внутри atom ноды, там может происходить что угодно. Но это простой вариант, в котором односторонняя связь proseMirror->что-нибудь. Если из компонентов нужно иметь воздействие на контент то уже не подойдёт. Для двусторонней придется попотеть с плагином, его я уже так быстро не опишу, но и супер-сложного там нет.
Почему формат proseMirror не удобен? На это я не смогу ответить. Основная проблема, что формат хранения был у нас уже до выбора решения для визивига. Предполагалось, что мы возьмём визивиг, который будет в нашем формате данные брать:) Оказалось, что таких нет, а клиенты уже пользуются нашим форматом.
Почему Вы решаете за нас, какие сообщения для дева, а какие нет? Разве мы не можем пользоваться этими сообщениями на проде? Например кто-то видит поведение, которое считает неправильным, мы просим показать консоль, а потом объясняем, что так и должно быть и почему или фиксим.
На скрине только ошибки от Вашего эдблока Ладно бы Вы показали что-то действительно полезное. Могли бы и повнимательнее посмотреть на ошибки.
Мы, разумеется, сначала накидали примерную схему sb, которая отвечала бы нашим требованиям, и искали что-то подобное, может недостаточно тщательно.
Обсудить и реализовать формат было довольно быстро. Основная работа с форматом была в специфике проекта. Различные эмбеды, обязательные поля, требования к данным разных клиентов. Это было бы в одном объеме сделано вне зависимости от стартового формата, так что ничего страшного не произошло.
И это немного не про визивиг. Когда мы пришли к непосредственной разработке его у нас не стоял выбор формата уже.
Нет. Мы рассматривали только описанные выше 3, из-за хранения в json. Конвертация html>sb довольно непростой процесс, жить с которым постоянно было бы больно.
В целом, мы и взяли готовый фреймворк для визивига. Без proseMirror разработка бы не была обоснована совсем. Я уверен, что с trix мы бы решали несколько больше проблем, чем с proseMirror.
Tiny в таком случае не гарантирует консистентности. У нас точно будут потери на этапе html>sb, а значит это уже не wysiwyg. Структура, которую он выдает, не очень похожа на плоское представление информации. Плюс есть достаточное количество абсолютно лишних тэгов, которые он вставляет, особенно при копипасте из гугл-доков. Ну и к этому всему в tiny нельзя поставить каких-то жестких рамок ни по структуре данных, ни по представлению определенных типов.
Например: картинка с подписью. В tiny мы либо пишем плагин который будет работать с картинками именно так, как нам нужно(и я не уверен, что получится в полной мере), либо редактор (блогер) будет каждый раз сам придумывать, как ему сделать эту подпись(в каждом материале будет не по дизайну).
Как здорово, что не разработчики являются бизнес-оунерами, вот мы бы наворотили иначе.