Как стать автором
Обновить

Комментарии 41

Разработчики очень любят создавать проблемы и их решать. А больше всего нам нравится писать велосипеды.

Вы забыли про костыли.
Как здорово, что не разработчики являются бизнес-оунерами, вот мы бы наворотили иначе.
Можете, пожалуйста, пояснить, что вы имеете в виду под велосипедом? Это была большая задача по переезду на новый стек, в проектировании решения которой было задействовано много людей от продакт-менеджеров и дизайнеров до девопс-инженеров, суть которой мы постарались отразить в разделе «1.2. Описание задачи, которая стояла перед разработчиками». Смысл был в том, что нам не нужен был просто какой-нибудь онлайн-редактор. Нам нужен был редактор, который:
  • соответствует нашей дизайн-системе,
  • удовлетворяет потребностям наших пользователей,
  • интегрируется в действующий проект,
  • может быть переиспользован на других проектах в компании,
  • весит как можно меньше.


Разработчики из The New York Times в своей статье про то, как они разрабатывали свой WYSIWYG-редактор, где описывается похожий кейс, прямо говорят, что было не очень-то просто.
Text editors are much more complex than many know.
Text editors are much more complex than many know.

Написание сложного кода с нуля это и есть велосипедостроение:
  • Сложные пользовательские сценарии ведут к багам
  • Большое количество элементов разметки и их сочетаний
  • Юникод и эмодзи, лигеатуры
  • Еще миллион пунктов

Однако, если целью было опредено занять программеров, то тогда имело смысл изобретать)
Кажется, не очень поняла последний коммент. Сложный код ведет к багам, да. Если можно не разрабатываться что-то сложное с нуля, то лучше этого не делать, конечно. Но бывают также случаи, когда готовые решения не подходят и приходится самим писать что-то большое и сложное.
«в TinyMCE нельзя загружать картинки напрямую из файла» — для этого есть несколько плагинов разных разработчиков. Мы писали свой, и это несколько проще, чем менять редактор.
Дело вообще не в Tiny, дело в формате данных. Главная задача была «не хранить HTML». Нужна была довольно плоская структура, удобная для всех клиентов и бэка в виде JSON.

Но, насколько можно понять, пришлось сделать конвертер HTML > SB и SB > HTML. Если так, то можно ехать дальше на старом добром TinyMCE. Верно?

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

Tiny в таком случае не гарантирует консистентности. У нас точно будут потери на этапе html>sb, а значит это уже не wysiwyg. Структура, которую он выдает, не очень похожа на плоское представление информации. Плюс есть достаточное количество абсолютно лишних тэгов, которые он вставляет, особенно при копипасте из гугл-доков. Ну и к этому всему в tiny нельзя поставить каких-то жестких рамок ни по структуре данных, ни по представлению определенных типов.
Например: картинка с подписью. В tiny мы либо пишем плагин который будет работать с картинками именно так, как нам нужно(и я не уверен, что получится в полной мере), либо редактор (блогер) будет каждый раз сам придумывать, как ему сделать эту подпись(в каждом материале будет не по дизайну).

Смотрели на https://trix-editor.org/?
Понял, но всегда есть стоимость решения. Иногда готовое, но слегка допиленное лучше, чем сделать большое и постоянно инвестировать в допиливание. В вашем случае наверное это было целесообразно.

Нет. Мы рассматривали только описанные выше 3, из-за хранения в json. Конвертация html>sb довольно непростой процесс, жить с которым постоянно было бы больно.
В целом, мы и взяли готовый фреймворк для визивига. Без proseMirror разработка бы не была обоснована совсем. Я уверен, что с trix мы бы решали несколько больше проблем, чем с proseMirror.

Все именно так, как написал buyanzashitkarman.
В принципе, можно было бы не делать новый редактор, а просто добавить автосохранение и возможность загрузки картинок в собственное хранилище – и большая часть жалоб пользователей и сотрудников отпала бы. Но хотелось все же не поддерживать инструмент на старых технологиях, а создать новый современный редактор, который мы сможем легко развивать и масштабировать.

То есть, мы понимали, что можно было остаться с TinyMCE, но хотелось именно отказаться от его главного недостатка — хранение контента в HTML.

Городская легенда гласит, что когда-то и на Хабре появится визивиг редактор. Но легенда на то и легенда...

Если я правильно понял, вы придумали свой велосипед в виде формата structured body, были ли причины не взять mobiledoc?
github.com/bustle/mobiledoc-kit/blob/master/MOBILEDOC.md
github.com/alidlo/vue-mobiledoc-editor

Например, редактор в ghost.org использует mobiledoc формат.

Мы, разумеется, сначала накидали примерную схему sb, которая отвечала бы нашим требованиям, и искали что-то подобное, может недостаточно тщательно.
Обсудить и реализовать формат было довольно быстро. Основная работа с форматом была в специфике проекта. Различные эмбеды, обязательные поля, требования к данным разных клиентов. Это было бы в одном объеме сделано вне зависимости от стартового формата, так что ничего страшного не произошло.
И это немного не про визивиг. Когда мы пришли к непосредственной разработке его у нас не стоял выбор формата уже.

Чумной доктор? #pareidolia

image

Уже больше года практически везде использую editor.js от ребят из vc.ru и иже с ними, всем доволен, плюс сделать связку с react, vue или ещё с чем достаточно просто.

Спасибо! Выглядит действительно как инструмент, который мог бы нам подойти сейчас. Когда мы выбирали библиотеку 1.5 года назад, мы про него не подумали. Возможно, он был не такой популярный, как остальные. Кроме того, опыт The New York Times и The Guardian, остановившихся на ProseMirror подкупал. Мы ни в коем случае не настаиваем на том, что наше решение лучшее из имеющихся. Как раз поделились своим опытом, чтобы кто-то не наступил на какие-то наши грабли.
Вот почитаешь такие посты и думаешь «не фига себе как всё круто! какие там профессионалы работают». А потом пытаешься пользоваться этим порталом и понимаешь, что… ну неюзабельно это!
В полях комментариев экранируется символ перевода строки.
Страницы с большим количеством комментариев начинают дико тупить при попытке прогрузить эти комментарии (причём чем дальше мотаешь, тем сильнее тупит — то ли там какие-то манипуляции со всем DOMом, то ли ещё что).
Вообще, бесконечный скролл для ленты комментариев — офигенное дизайнерское решение! Особенно когда этих комментариев за тысячу.
А «тупящий» аякс, который уведомление о новых ответах показывает почему-то спустя некоторое врем после загрузки страницы.
А как вы загородили рекламой навигационное меню?
Вообще у ресурса такого уровня, на продакшене, в консоли должно быть девственно чисто:
image
Зато про неработающий(!) «AntiAdBlock» не забыли))

sports.ru — это крайне сырой, некачественный продукт с точки зрения фронтенда.
Благодарю за разбор нашего сайта. Действительно, у нас далеко не все идеально, проект старый, с кучей легаси. Мы о своих проблемах знаем и работаем над ними. В том числе описанный в статье кейс является частью работ по приведению всего в порядок. Если вы знаете, как справиться лучше и быстрее, то у нас как раз открыто несколько вакансий.

На скрине только ошибки от Вашего эдблока Ладно бы Вы показали что-то действительно полезное. Могли бы и повнимательнее посмотреть на ошибки.

А я ничего и не выбирал. Скриншот как есть. Понятно что ERR_BLOCKED_BY_CLIENT — это адблок. Но парсер json-то почему ошибки выбрасывает?

Вот с отключенными блокировщиками:
image

Ну и заодно — консольные сообщения для дева, перед продакшеном-то стоит всё-таки вычищать. А то что это за хвосты «не выполнены условия показа попапа»?

Почему Вы решаете за нас, какие сообщения для дева, а какие нет? Разве мы не можем пользоваться этими сообщениями на проде? Например кто-то видит поведение, которое считает неправильным, мы просим показать консоль, а потом объясняем, что так и должно быть и почему или фиксим.

Потому что это непрофессионально. В идеале должен быть флаг у каждого пользователя, позволяющий перевести его в debug-режим прямо из админки с автоматизированной отправкой фронтовых логов на сервер, чтобы ему не нужно было слать вам скриншотики. В чуть худшем случае — некий query string параметр, который включит дебаг. Но ни в коем случае не срать в консоль всегда и для всех

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

Блокировщики рекламы — это сторонние приложения, которые переопределяют стили, блокируют запросы и всячески хозяйничают на странице. При этом их поведение может зависеть от того, какие у вас настройки выбраны, какие белые и черные списки подключены и т.д. На данный момент бизнес-модель Sports.ru такова, что мы получаем деньги от рекламы, поэтому можем гарантировать корректную работу сайта только с отключенными блокировщиками. Мы не игнорируем совсем подобные проблемы, но как правило приоритет у них довольно низкий.

За tinyMCE обидно было :) Список претензий команды к нему не оч актуальный. tinyMCE позволяет сделать собственную обработку вставки картинки и грузить её хоть с диска сразу в хранилище, хоть с выбором готовой из хранилища — как угодно. Список стилей там тоже конфигурируется. Из коробки можно добавить свой стиль для внутренних загов.
Но для современного визивига лабания статей и логридов, когда нужна тильда, он конечно не подойдет. Мы тоже с него соскочили.

Важнее всего было уйти от сохранения контента в HTML. Тут tiny уже ничего не мог предложить, к сожалению.

Решали подобную задачу с помощью editor.js. Странно, что его нет в списке, все что вам было нужно, там из коробки + 0 зависимостей + отечественные разрабы.

К сожалению, мы на него наткнулись около года назад, когда у нас уже был готов прототип и мы готовились к запуску своей беты. Тут важно понимать, что выбор инструмента и проектирование происходили где-то в середине 2018 года. Мы рассмотрели те библиотеки, которые были популярны в момент исследования. С конца 2018 года уже начался активный этап разработки.
в проекте заюзали вот такое решение github.com/scrumpy/tiptap. Пока полет нормальный
Да, стабильный релиз этой библиотеки вышел уже, когда мы уже готовили бету. А так бы с удовольствием сами использовали
Спасибо за ваш опыт.

Мне интересно, вы видите сейчас смысл в своей созданной схеме «structured body», когда у ProseMirror есть своя схема?

У вас же вроде лишние конвертации между этими схемами идут и ваша схема очень похожа на ту что в ProseMirror если судить по примеру.
Если бы у нас был один небольшой проект, то наверное формата ProseMirror нам бы и правда хватило (на одном небольшом промо-проекте, где нужен был редактор текста, так и сделали). Проблема тут в том, что формат ProseMirror не очень удобен для хранения данных и последующей работы с ними, все же задумывался он для другого.
И кроме того, когда мы начинали работу над редактором, наш формат structured body, который нам подходил и по поводу которого мы были уверены, что мы с ним надолго, уже был утвержден. buyanzashitkarman уже писал про это в комментарии чуть выше

Tui.editor работает с markdown разметка и классический html одновремено.


Конвертит из буфера автоматом картинки в base64
Загрузку на сервер тоже есть


На сервере храню в markdown меньше объем.

Удивлен, что никто не упомянул ckeditor 5. На нем можно сделать практически что угодно, если разобраться с его внутренностями и использовать как фреймворк (а не готовые билды).

Мы в Atlassian тоже используем ProseMirror как основу для редакторов в BitBucket, Confluence, Jira, etc…  Пример можно посмотреть на нашем сайте дизайн системы: atlaskit.atlassian.com/examples/editor/editor-core/kitchen-sink

Тоже переходили с TinyMCE так как менеджить его очень тяжело, HTML не самый удобный формат для хранения данных.

Вообще ваш опыт очень похож на то что мы делаем. Мы также пытались решить forwards compatibility с использование unsupportedBlock который, по описанию, выглядит один в один как ваш :) Но мы также используем подмножество ProseMirror JSON как дата формат. Интересно послушать почему по Вашему мнению он не удобен для хранения данных? И у нас также есть json schema для валидации документов.

Одна из самых больших проблем для нас – это переиспользование реакт компонентов из дизайн системы внутри контента редактора. Как я понимаю вы делаете что-то похоже но с Vue, или у вас только plain ProseMirror?

Спасибо за комментарий. Я не совсем понял про использование реакт компонентов в контенте. Вы про использование их в момент использования редактора, или про саму контентную страницу? С контентными страницами кажется всё довольно простым: мы итерируем элементы в массиве данных и вольны выбирать как их отрисовывать, как компонент или как строку. В самом редакторе мы Vue компоненты ещё пока не использовали, но, скорее всего, будем это делать как и эмбеды. У proseMirror в схеме написано, что нужно вставить вот такой с такими дата-аттрибутами и потом вызвать вот эту функцию. В функции можно выбросить событие или воспользоваться заранее прокинутым API с react. Так как proseMirror уже не сильно важно, что происходит внутри atom ноды, там может происходить что угодно. Но это простой вариант, в котором односторонняя связь proseMirror->что-нибудь. Если из компонентов нужно иметь воздействие на контент то уже не подойдёт. Для двусторонней придется попотеть с плагином, его я уже так быстро не опишу, но и супер-сложного там нет.
Почему формат proseMirror не удобен? На это я не смогу ответить. Основная проблема, что формат хранения был у нас уже до выбора решения для визивига. Предполагалось, что мы возьмём визивиг, который будет в нашем формате данные брать:) Оказалось, что таких нет, а клиенты уже пользуются нашим форматом.

У proseMirror в схеме написано, что нужно вставить вот такой <div> с такими дата-аттрибутами и потом вызвать вот эту функцию

Про удобство могу ответить я. Это мое личное мнение, которое я плохо выразила. Схема structured body предполагает меньше уровней вложенности и глядя на контент в этом формате можно просто быстрее понять структуру DOM-дерева, которое будет построено. Полагаю, что у автора ProseMirror были причины делать, например, марки в виде отдельного массива объектов со своими типами и атрибутами, а также включать ссылку в список марок. Это все детали, конечно. Безусловно, у нас не стоял выбор между форматом ProseMirror и structured body, потому что последний уже был принят. Но лично мне разбираться в схеме формата ProseMirror было немного сложнее.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.