Школа
Управление

Как вы оцените с технической точки зрения новый редактор публикаций в «Деле Модульбанка»?

Как вы оцените с технической точки зрения новый редактор публикаций в «Деле Модульбанка» — https://intuition.team/delo-control-panel? Какие технологии и фреймворки вы бы порекомендовали, чтобы сделать что‑то подобное у себя на сайте?

Александр Колодько
21 янв 2021
👁 8263   🗩3
Управление

Как вы оцените с технической точки зрения новый редактор публикаций в «Деле Модульбанка»?

Как вы оцените с технической точки зрения новый редактор публикаций в «Деле Модульбанка» — https://intuition.team/delo-control-panel? Какие технологии и фреймворки вы бы порекомендовали, чтобы сделать что‑то подобное у себя на сайте?

Александр Колодько
21 янв 2021
👁 8263   🗩3
Фёдор Борщёв
Программист, стартапер, ИТ‑консультант
Полезно
 6
6
Непонятно
 1
1
Войдите в Бюросферу, чтобы голосовать

Сразу предупрежу, что я не запустил ни одного успешного медиа, поэтому порассуждаю как разработчик. Определённо, у команды «Дела» были серьёзные причины не брать готовые инструменты вроде GraphCMS или хотя бы редакторы вроде Quill, Vev или отечественной Сетки.

Мне нравится идея с библиотекой готовых компонентов: редакторы не изобретают форматы, а пользуются готовыми компонентами, которые точно выглядят хорошо. При этом в исключительных случаях формат можно и изобрести — к программистам идти не придётся. Похожая библиотека используется и в советах бюро.

С точки зрения удобства меня смущает Паг. По сравнению с обычным текстом, поддерживать длинные документы на Паге — мучение. На нём, как и на любом языке программирования, легко ошибиться — не закрыть скобочку, поставить неправильный отступ или перепутать ( и ]. Но, в отличие от ХТМЛ или того же Питона, у Пага нет онлайн‑подсветки, которая покажет ошибку во время редактирования: вы не узнаете, что ошиблись, пока не запустите компиляцию. Надеюсь, разработчики «Дела» нашли обходной путь, к примеру рендерят текст прямо в процессе редактирования и показывают ошибки где‑нибудь рядом с окном редактирования.

Паг — это целый язык программирования: с переменными, функциями, операторами ветвления, итераторами, сниппетами и фильтрами. Вряд ли редакторы используют хоть что‑то из этого — скорее всего они просто пишут тексты с вкраплениями разметки. А значит, вместо Пага гораздо лучше подошёл бы обычный Маркдаун: текст из текстового редактора в нём выглядит хорошо, но при желании в него так же легко вставить любой ХТМЛ. В отличие от Пага, Маркдаун терпим к человеческим ошибкам, да и порог входа у него ниже. Сравните, как выглядит текст на Маркдауне и на Паге:

Маркдаун
Редакторы пишут как привыкли:
  * Не думают про HTML
  * В любимом приложении типа _IA Writer_
  * Текст легко **выделять**
  * Но можно вставить <strong>HTML</strong>, если вдруг забыл синтаксис
Паг
p Редакторы пишут как привыкли:
ul
  li Не думают про HTML
  li В любимом приложении типа \#[i IA Writer] писать уже не получается
  li Выделять текст \#[b сложно, но можно]
  li Вставить <strong>HTML</strong>, если вдруг забыл синтаксис, тоже можно

Кроме ЦСС в итоговой разметке, для расширения Маркдауна есть интересные задумки вроде mdx, которые позволяют использовать в тексте компоненты Реакта.

Знаете, чем Паг удобнее Маркдауна? Напишите в комментариях!

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Управление проектомВеб‑разработка
Полезно
 6
6
Непонятно
 1
1
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

Прокомментирую как главный редактор, основатель и руководитель Дела Модульбанка. Ненавижу маркдаун!

Людмила, не расскажете подробнее, чем вам неприятен маркдаун?

Я пишу техническую документацию, используя разметку reStructuredText. Она чуть посложнее маркдауна, но богаче по возможностям. Главное — есть семантическая разметка. Можно обозначить, что вот это — термин, это — название элемента интерфейса, а то — блок кода. А то, как будет выглядеть термин, название кнопки или пример кода, задаётся, например, в CSS‑стилях для сайта. Если захотим отображать термины другим стилем, сможем поменять отображение, не редактируя тексты. Markdown и Pug позволяют только выделить текст заранее заданным стилем, вроде полужирного или курсива, либо повесить на текст конкретный класс. В обоих случаях автор текста вручную задаёт отображение элементов текста, и это хуже, чем задавать их семантику и делегировать отображение.

Ещё reStructuredText строже, и ошибки обнаруживаются сразу (fail‑fast). Например, когда мы указали несуществующий адрес в ссылке, или когда открыли и не закрыли внутристрочную разметку. Markdown или HTML, наоборот, позволяют ошибаться сколько угодно. Это приемлемо, когда пользователи сайта пишут комментарии и мы хотим показать их хоть как‑нибудь, даже с ошибками. Но ошибки в профессиональных текстах лучше находить и исправлять сразу, до публикации.

Кроме reStructuredText есть ещё язык разметки AsciiDoc. Он столь же хорош и семантичен. Выбор между двумя этими языками — дело вкуса и заточки под конкретные задачи.

Цель рубрики — обсуждение вопросов дизайна, веб-разработки, переговоров, редактуры и управления.
Комментарии модерируются. Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры.

Рекомендуем другие советы