Comments 29
Извините, но самое сложное в markdown — помечать заголовки символами "#"… Разве обучить менеджера markdown сложнее, чем написать текстовый блочный редактор со встроенным html-конвертером?
Ну, первое, что гуглится — какой-то Martor, его вполне должно хватить, судя по фичам. А какие Вы хотите плагины?
Опыта именно с этим редактором нет, насчет плагинов не знаю. Какие именно плагины вы хотите?
Markdown — это же просто соглашение о том, как писать текст. По этим соглашениям можно описать в простом тексте форматирование (жирный, курсив), абзацы, заголовки, списки (нумерованные и ненумерованные), картинки, простые таблицы. Вам необходимо использовать еще что-то кроме этого?
Нам нужно интегрировать glvrd.ru как нам его впихнуть в ваш Martor?
А вот в Editor.js мы его интегрировали за 30 минут. Понимаете?
Но, как говорится, на вкус и цвет все фломастеры разные… лично мне ближе markdown, другим подойдет json формат :)
И много преимуществ Вы получаете от того, что в базе текст статьи хранится как json, а не как текст?
{
"type" : "header",
"data" : {
"text" : "Описание главной проблемы",
"level" : 3
}
},Или например список:
{
"type" : "list",
"data" : {
"style" : "Формат данных:",
"items" : [
"1.",
"2.",
"3."
]
}
},React native получает объект и с ним работает, как мне получить такой объект в переменную в react native?
Так есть WYSIWYG Markdown редакторы, в которых синтаксис знать не обязательно. Например, онлайновый StackEdit и оффлайновая https://typora.io/.
А как её написать в любом другом формате? По идее, вставить соответствующий блок, внешний по отношению к формату. Или где-то это есть "из коробки"?
В некоторых ситуациях эта проблема несущественна, например, если вам нужно быстро набрать большое количество текста с минимальными правками. Но если вам приходится часто заниматься редактурой уже написанных текстов, перемещая одни куски текста и переписывая другие, то WYSIWYG Markdown-редакторы могут оказаться удобнее в использовании.
Не совсем понял, как это могло бы помочь. Или вы предлагаете переключиться в режим просмотра, выделить текст, переключиться обратно, и чтобы выделение сохранилось? Мне кажется, так сделать не получится, потому что смежные параграфы реализованы отдельными contenteditable-блоками. Представьте, что каждый параграф — это отдельный textarea, просто без рамок. Очевидно, что нельзя начать выделять текст в одном textarea и продолжить выделение в следующем.
Вообще в стандартных контролах для редактирования текста (как в браузере, так и в десктопных приложениях) существует много "мелочей", которые, как мне кажется, большинством людей воспринимается как данность, доступная повсеместно из коробки или же легко реализуемая. Помню, как в самом начале моей карьеры тимлид поручил мне "набросать по-быстрому простой WYSIWYG-редактор" для десктопного приложения, которое мы разрабатывали. Все нужно было отрисовать на Windows GDI: рамку, курсор, скроллбар, выделение, ну и, конечно, отрендерить сам текст. К счастью, никаких картинок или таблиц. По оценке тимлида у него бы на это ушло два дня, но поскольку я был тогда джуниор, то мне он щедро выделил аж целых четыре дня. У меня на все это ушло три недели с дикими овертаймами. (К концу разработки мне уже в буквальном смысле снились кошмары про то, что я забыл учесть кернинг при расчете ширины текста.) Еще через неделю, после того, как это ушло в продакшн, пользователи прислали нам несколько десятков багрепортов вида: «А что это я тут нажимаю Shift+Ctrl+End (выделить от курсора до конца текста), а оно не работает?» Еще через две недели, потраченные на то, чтобы попытаться все это реализовать, тимлид плюнул и решил заменить наш контрол на стандартный RichTextBox. Пусть он корявый и ущербный (например, выравнивание текста по ширине, которое так хотел тимлид, в нем не поддерживается), но зато все "мелочи" в нем, в отличие от нашего велосипеда, реализованы на 100%.
В вебе ситуация еще более плачевная, поскольку к итак уже непростой задаче добавляются еще и ограничения браузера (если, конечно, вы не на канвасе все вручную рисуете — но тогда вам остается только посочувствовать). Есть прекрасный блог Content Uneditable от разработчиков CKEditor и вводная статья ContentEditable — The Good, the Bad and the Ugly, которая наглядно показывает масштаб проблемы, с которой сталкиваются начинающие разработчики, которые решили разработать свой онлайн-редактор и еще не подозревают, сколько "мелочей" им придется реализовать самостоятельно. Проиллюстрирую на примере Editor.js. Возьмем несколько абзацев текста, кликнем в середину первого абзаца и несколько раз нажмем кнопку "вниз" на клавиатуре. Сначала посмотрим, как это работает в "обычных" текстовых редакторах (Microsoft Word в качестве примера):
Обратите внимание, как Word старается, по возможности, точно сохранить горизонтальную позицию курсора при переходе между строками и абзацами.
Теперь тот же самый эксперимент на главной странице Editor.js:
Можно заметить, что при переходе между смежными абзацами позиция курсора теряется. (Плюс еще в конце каждого абзаца курсор сначала прыгает в конец строки перед переходом к следующему абзацу — ожидаемое поведение, если вспомнить, что каждый абзац ведет себя как отдельная textarea.) Можно возразить, что это мелочи — подумаешь, придется лишний раз кликнуть мышью — но из таких мелочей и складывается тот самый "user experience". Представьте себе контент-менеджера, годами пользовавшегося редакторами, которые ведут себя подобно Microsoft Word. У него все эти "мелочи" уже чуть ли ни на уровне мышечной памяти, поэтому процесс привыкания к поведению нового редактора у него будет выглядеть как-то так: нажал что-то на автомате -> получил неожиданный результат -> удивился -> вспомнил, что тут все не так -> в очередной раз проклял разработчиков -> исправил и продолжил работу до возникновения следующей проблемы. В результате он либо все-таки переучится, ценой потраченных нервов, либо плюнет на все и будет набирать текст в Word, а затем копировать результат в онлайн-редактор.
Editor.js прекрасный редактор сохраняющий исходный код в JSON формате