Comments 41
Разработчики очень любят создавать проблемы и их решать. А больше всего нам нравится писать велосипеды.
Как здорово, что не разработчики являются бизнес-оунерами, вот мы бы наворотили иначе.
- соответствует нашей дизайн-системе,
- удовлетворяет потребностям наших пользователей,
- интегрируется в действующий проект,
- может быть переиспользован на других проектах в компании,
- весит как можно меньше.
Разработчики из The New York Times в своей статье про то, как они разрабатывали свой WYSIWYG-редактор, где описывается похожий кейс, прямо говорят, что было не очень-то просто.
Text editors are much more complex than many know.
Text editors are much more complex than many know.
Написание сложного кода с нуля это и есть велосипедостроение:
- Сложные пользовательские сценарии ведут к багам
- Большое количество элементов разметки и их сочетаний
- Юникод и эмодзи, лигеатуры
- Еще миллион пунктов
Однако, если целью было опредено занять программеров, то тогда имело смысл изобретать)
Но, насколько можно понять, пришлось сделать конвертер HTML > SB и SB > HTML. Если так, то можно ехать дальше на старом добром TinyMCE. Верно?
Tiny в таком случае не гарантирует консистентности. У нас точно будут потери на этапе html>sb, а значит это уже не wysiwyg. Структура, которую он выдает, не очень похожа на плоское представление информации. Плюс есть достаточное количество абсолютно лишних тэгов, которые он вставляет, особенно при копипасте из гугл-доков. Ну и к этому всему в tiny нельзя поставить каких-то жестких рамок ни по структуре данных, ни по представлению определенных типов.
Например: картинка с подписью. В tiny мы либо пишем плагин который будет работать с картинками именно так, как нам нужно(и я не уверен, что получится в полной мере), либо редактор (блогер) будет каждый раз сам придумывать, как ему сделать эту подпись(в каждом материале будет не по дизайну).
Смотрели на https://trix-editor.org/?
Понял, но всегда есть стоимость решения. Иногда готовое, но слегка допиленное лучше, чем сделать большое и постоянно инвестировать в допиливание. В вашем случае наверное это было целесообразно.
Нет. Мы рассматривали только описанные выше 3, из-за хранения в json. Конвертация html>sb довольно непростой процесс, жить с которым постоянно было бы больно.
В целом, мы и взяли готовый фреймворк для визивига. Без proseMirror разработка бы не была обоснована совсем. Я уверен, что с trix мы бы решали несколько больше проблем, чем с proseMirror.
В принципе, можно было бы не делать новый редактор, а просто добавить автосохранение и возможность загрузки картинок в собственное хранилище – и большая часть жалоб пользователей и сотрудников отпала бы. Но хотелось все же не поддерживать инструмент на старых технологиях, а создать новый современный редактор, который мы сможем легко развивать и масштабировать.
То есть, мы понимали, что можно было остаться с TinyMCE, но хотелось именно отказаться от его главного недостатка — хранение контента в HTML.
Городская легенда гласит, что когда-то и на Хабре появится визивиг редактор. Но легенда на то и легенда...
github.com/bustle/mobiledoc-kit/blob/master/MOBILEDOC.md
github.com/alidlo/vue-mobiledoc-editor
Например, редактор в ghost.org использует mobiledoc формат.
Мы, разумеется, сначала накидали примерную схему sb, которая отвечала бы нашим требованиям, и искали что-то подобное, может недостаточно тщательно.
Обсудить и реализовать формат было довольно быстро. Основная работа с форматом была в специфике проекта. Различные эмбеды, обязательные поля, требования к данным разных клиентов. Это было бы в одном объеме сделано вне зависимости от стартового формата, так что ничего страшного не произошло.
И это немного не про визивиг. Когда мы пришли к непосредственной разработке его у нас не стоял выбор формата уже.
Уже больше года практически везде использую editor.js от ребят из vc.ru и иже с ними, всем доволен, плюс сделать связку с react, vue или ещё с чем достаточно просто.
В полях комментариев экранируется символ перевода строки.
Страницы с большим количеством комментариев начинают дико тупить при попытке прогрузить эти комментарии (причём чем дальше мотаешь, тем сильнее тупит — то ли там какие-то манипуляции со всем DOMом, то ли ещё что).
Вообще, бесконечный скролл для ленты комментариев — офигенное дизайнерское решение! Особенно когда этих комментариев за тысячу.
А «тупящий» аякс, который уведомление о новых ответах показывает почему-то спустя некоторое врем после загрузки страницы.
А как вы загородили рекламой навигационное меню?
Вообще у ресурса такого уровня, на продакшене, в консоли должно быть девственно чисто:
Зато про неработающий(!) «AntiAdBlock» не забыли))
sports.ru — это крайне сырой, некачественный продукт с точки зрения фронтенда.
На скрине только ошибки от Вашего эдблока Ладно бы Вы показали что-то действительно полезное. Могли бы и повнимательнее посмотреть на ошибки.
Ну и заодно — консольные сообщения для дева, перед продакшеном-то стоит всё-таки вычищать. А то что это за хвосты «не выполнены условия показа попапа»?
Почему Вы решаете за нас, какие сообщения для дева, а какие нет? Разве мы не можем пользоваться этими сообщениями на проде? Например кто-то видит поведение, которое считает неправильным, мы просим показать консоль, а потом объясняем, что так и должно быть и почему или фиксим.
Потому что это непрофессионально. В идеале должен быть флаг у каждого пользователя, позволяющий перевести его в debug-режим прямо из админки с автоматизированной отправкой фронтовых логов на сервер, чтобы ему не нужно было слать вам скриншотики. В чуть худшем случае — некий query string параметр, который включит дебаг. Но ни в коем случае не срать в консоль всегда и для всех
С включённым адблоком на сайте иногда присутствует огромный пустой контейнер для рекламы на половину экрана. Когда я об этом написал в тех поддержку, мне сказали расслабиться и отключить адблок)
За tinyMCE обидно было :) Список претензий команды к нему не оч актуальный. tinyMCE позволяет сделать собственную обработку вставки картинки и грузить её хоть с диска сразу в хранилище, хоть с выбором готовой из хранилища — как угодно. Список стилей там тоже конфигурируется. Из коробки можно добавить свой стиль для внутренних загов.
Но для современного визивига лабания статей и логридов, когда нужна тильда, он конечно не подойдет. Мы тоже с него соскочили.
Решали подобную задачу с помощью editor.js. Странно, что его нет в списке, все что вам было нужно, там из коробки + 0 зависимостей + отечественные разрабы.
Мне интересно, вы видите сейчас смысл в своей созданной схеме «structured body», когда у ProseMirror есть своя схема?
У вас же вроде лишние конвертации между этими схемами идут и ваша схема очень похожа на ту что в ProseMirror если судить по примеру.
И кроме того, когда мы начинали работу над редактором, наш формат structured body, который нам подходил и по поводу которого мы были уверены, что мы с ним надолго, уже был утвержден. buyanzashitkarman уже писал про это в комментарии чуть выше
Tui.editor работает с markdown разметка и классический html одновремено.
Конвертит из буфера автоматом картинки в base64
Загрузку на сервер тоже есть
На сервере храню в markdown меньше объем.
Удивлен, что никто не упомянул ckeditor 5. На нем можно сделать практически что угодно, если разобраться с его внутренностями и использовать как фреймворк (а не готовые билды).
Тоже переходили с TinyMCE так как менеджить его очень тяжело, HTML не самый удобный формат для хранения данных.
Вообще ваш опыт очень похож на то что мы делаем. Мы также пытались решить forwards compatibility с использование unsupportedBlock который, по описанию, выглядит один в один как ваш :) Но мы также используем подмножество ProseMirror JSON как дата формат. Интересно послушать почему по Вашему мнению он не удобен для хранения данных? И у нас также есть json schema для валидации документов.
Одна из самых больших проблем для нас – это переиспользование реакт компонентов из дизайн системы внутри контента редактора. Как я понимаю вы делаете что-то похоже но с Vue, или у вас только plain ProseMirror?
Спасибо за комментарий. Я не совсем понял про использование реакт компонентов в контенте. Вы про использование их в момент использования редактора, или про саму контентную страницу? С контентными страницами кажется всё довольно простым: мы итерируем элементы в массиве данных и вольны выбирать как их отрисовывать, как компонент или как строку. В самом редакторе мы Vue компоненты ещё пока не использовали, но, скорее всего, будем это делать как и эмбеды. У proseMirror в схеме написано, что нужно вставить вот такой с такими дата-аттрибутами и потом вызвать вот эту функцию. В функции можно выбросить событие или воспользоваться заранее прокинутым API с react. Так как proseMirror уже не сильно важно, что происходит внутри atom ноды, там может происходить что угодно. Но это простой вариант, в котором односторонняя связь proseMirror->что-нибудь. Если из компонентов нужно иметь воздействие на контент то уже не подойдёт. Для двусторонней придется попотеть с плагином, его я уже так быстро не опишу, но и супер-сложного там нет.
Почему формат proseMirror не удобен? На это я не смогу ответить. Основная проблема, что формат хранения был у нас уже до выбора решения для визивига. Предполагалось, что мы возьмём визивиг, который будет в нашем формате данные брать:) Оказалось, что таких нет, а клиенты уже пользуются нашим форматом.
Как в Sports.ru писали свой WYSIWYG-редактор