Существует множество редакторов MarkDown. На самом деле, их так много, что меня заставили разглагольствовать об их текущем состоянии не так давно, и я рассмотрел сильного конкурента в этой области в надежде найти приложение MD Святого Грааля, но безрезультатно.
StackEdit 4.0
StackEdit в течение всего этого времени оставался на вершине мира редакторов MD, основанных на браузерах, но ему всегда не хватало чего-то определенного. Управление документами было далеко не идеальным, с хаотичным боковым меню и отсутствием надлежащей опции быстрого поиска, а проверка орфографии не была родной, что вызывало ненужные потери производительности, особенно на больших документах. Счетчики статистики были не так доступны, как сейчас, и возможности расширения редактора были более ограничены. Также отсутствовало множество опций публикации, присутствующих в версии 4. Большинство из этих недостатков были устранены в бета-версии , но эта версия не была ни общедоступной, ни объявленной стабильной — вы использовали ее на свой страх и риск потери данных и сбоев. Я лично использовал это надежно в течение многих месяцев, но я понимаю колебание масс. Однако на прошлой неделе @benweet наконец-то выпустил исходный код версии 4 на Github и подготовил его к публичному выпуску.
Новые функции включают значительно улучшенную панель документов с надлежащим управлением папками, так что вы можете всегда оставаться на вершине своих файлов. Вы также можете искать любой документ в вашем стеке (очень важно, когда у вас есть сотни).
Синхронизация с облачными сервисами, такими как Dropbox, Google Drive, Github и другими, была значительно улучшена, и я лично уже некоторое время наслаждаюсь автоматической синхронизацией с Google Drive. Пока я печатаю, мои документы автоматически синхронизируются с моими облачными сервисами, поэтому нет страха потери данных.
Теперь вы также можете добавлять встроенные комментарии к своим документам, позволяя вам делиться ими с другими и динамично сотрудничать. Фактический обмен документами может все еще использовать некоторую работу, но одну вещь за один раз.
Запуск его локально
Здесь, в SitePoint, мы регулярно используем StackEdit. Однако, помимо возможности запуска нескольких экземпляров одновременно, распространенной жалобой всегда были блоки кода. В настоящее время мы используем подсветку кода в нашем бэкэнде, который требует тегов [ code ] Хотя в конечном итоге это изменится, факт остается фактом: прямой экспорт в HTML из StackEdit создает правильно классифицированные блоки <code><pre> Решение для экспорта пользовательских блоков кода должно быть достаточно простым для написания кода, но до сих пор исходный код StackEdit оставался недоступным, а предлагаемые расширения не были достаточно настраиваемыми.
Чтобы обойти это, начнем с установки StackEdit в экземпляр Homestead Improved.
Чтобы заставить StackEdit работать локально, сначала разверните обычный экземпляр Homestead Improved . Не нужно вносить какие-либо конкретные изменения, просто запустите его, как если бы вы начинали проект PHP — идентично тому, что вам говорит ссылка. Затем введите SSH в виртуальную машину и выполните следующие действия:
cd ~/Code
git clone https://github.com/benweet/stackedit
cd stackedit
npm install --no-bin-link
bower install
(export PORT=5000 && node server.js)
Это более или менее инструкции, изложенные здесь , только с измененным портом и добавленным флагом npm install
Флаг --no-bin-link Как мы узнали ранее , Vagrant и символические ссылки не очень хорошо уживаются на хостах Windows, поэтому, чтобы быть полностью кросс-платформенными, мы используем этот флаг здесь.
Примечание для хостов Windows: Если npm install Windows не может поддерживать имена файлов длиннее 260 символов , а NPM, являясь тем, чем он является, вложенных узловых_модулей может иметь несколько уровней подпапок, прежде чем попасть куда угодно. Загрузка виртуальной машины из более «корневого» местоположения обычно решает эту проблему — в моем конкретном случае, перемещая папку виртуальной машины в D:vagrant up
Затем, чтобы получить доступ к своему локально запущенному экземпляру StackEdit, просто зайдите на http://homestead.app:5000
Запуск нескольких экземпляров StackEdit
В своем первоначальном посте о состоянии редакторов MarkDown я отметил ограничение в одном экземпляре StackEdit как большой недостаток. И действительно, он большой — когда вы редактируете много постов, некоторые из которых являются частями одной серии, вам, как правило, приходится прыгать туда-сюда время от времени.
Когда веб-приложение использует локальное хранилище, этот контейнер локального хранилища привязывается к домену за сеанс. Это означает, что вы можете использовать несколько экземпляров StackEdit даже в исходной онлайн-форме, если откроете один в главном браузере, один в окне инкогнито, другой в другом браузере и т. Д. Это связано с тем, что каждая из этих комбинаций домен-сеанс является уникальной и использует свое собственное локальное хранилище. Но в эпоху, когда одна вкладка браузера может использовать более 4 ГБ ОЗУ (я смотрю на вас, Tweetdeck и Google+), открытие новых браузеров и окон — не идеальный подход.
Чтобы обойти это при локальном запуске нашего экземпляра StackEdit, мы можем легко определить несколько записей в файле hosts
127.0.0.1 test.app
127.0.0.1 test2.app
127.0.0.1 test3.app
Открытие http://test.app:5000http://test2.app:5000http://test3.app:5000
Те из вас, кто более внимателен, теперь могут задаться вопросом: «Но разве это не значит, что мы можем определить псевдонимы доменов в файле hosts Если мы stackedit.io54.236.87.105hosts
54.236.87.105 stack1.app
54.236.87.105 stack2.app
54.236.87.105 stack3.app
мы можем открыть живые размещенные стеки так же, как те, которые мы только что открыли локально, посетив stack1.app/stack2.app/stack3.app/ Однако есть предостережение — поскольку StackEdit является приложением Heroku, IP-адрес приложения может периодически меняться, и поддержание обновленного файла hosts Следовательно, наш Vagrant-хост-подход явно лучше — IP-адрес гарантированно останется на уровне 127.0.0.1
Обмен данными
Конечно, недостатком этого подхода является наличие трех отдельных баз данных локального хранилища — это разъединяет ваши вкладки StackEdit и не позволяет вам делиться файлами, которые вы редактируете, между этими «разными» экземплярами.
Это приведет к тому, что каждый экземпляр StackEdit будет отделен от остальных и не сможет получить доступ к данным других. Конечно, вы можете копировать и вставлять содержимое из одного в другое и поддерживать разные базы данных документов для каждого домена, но это слишком много работы. Есть два подхода, чтобы решить эту проблему.
1. Обмен данными LocalStorage
Этот подход может применяться как к онлайн, так и к вашим локально размещенным версиям. Как мы уже говорили ранее, данные локального хранилища уникальны для каждого источника (источником является комбинация домен + сеанс). Домен X не может получить доступ к локальному хранилищу домена Y, и по уважительной причине — если они не связаны, они не должны обмениваться данными.
Вот где этот пост пригодится. Сейчас ему почти четыре года, но он создал очень интересный проект . Проще говоря, вы можете использовать эту библиотеку для совместного использования localStorage между доменами, но вам нужно вручную вносить белый список в каждый домен. Другими словами, чтобы использовать это, вам нужно определить несколько записей хостов для ваших экземпляров StackEdit (будь то онлайн или локально), как мы делали выше, внести их в белый список, а затем реализовать некоторый простой код совместного использования localStorage. Детали реализации выходят за рамки этого поста, и, как только вы увидите второй подход, покажется несколько ненужным.
2. Отключение проверки уникальности
Единственное, что мешает StackEdit запускать два или более экземпляров одновременно, — это проверка уникальности, встроенная в приложение. Чтобы быть более точным, это вызов checkWindowUnique()public/res/core.js Прокомментируйте эту строку.
Затем запустите несколько вкладок с test.app:5000/?debug Параметр ?debuggrunt Если вы довольны изменениями, просто запустите gruntstackedit Если вы не сделаете несколько дополнительных настроек, чтобы сделать код JSHint-допустимым, вам нужно будет выполнить grunt с флагом --force
grunt --force
Это говорит о том, что он должен игнорировать проблемы JSHint (в конкретном случае выше, он скажет вам, что функция checkWindowUnique Легкий обходной путь без применения силы — это закомментировать эту функцию вместе со строкой, которая ее вызывает.
Теперь вы сможете запускать несколько экземпляров StackEdit в своем браузере, и все документы будут разделены между ними. Я уже некоторое время использую этот подход, и мне еще не приходилось сталкиваться с условиями гонки, из-за которых этот блок был реализован в первую очередь.
Если у нас есть StackEdit Tab1 (ST1) и StackEdit Tab2 (ST2) и файл X и файл Y, имейте в виду следующие правила:
- Если файл X открыт в ST1 и ST2, применяются изменения из последнего использованного ST. Редактирование файла X в ST1 и последующее обновление ST2 покажет вам содержимое файла X, представленного в ST1, и наоборот.
- Если файл X открыт в ST1 и ST2, и вы переключаете ST2 в файл Y, внесите некоторые изменения, затем обновите ST1, ST1 также будет переключен на файл Y. Это потому, что StackEdit использует localStorage для отслеживания вашего местоположения и открытия файлы и синхронизирует их, так что вы в конечном итоге, где вы остановились при повторном открытии приложения
Я не советую использовать этот хак для нескольких экземпляров для чего-либо, кроме чтения только одного документа при записи в другой. Все, что больше, становится хаотичным, довольно быстро.
Вывод
StackEdit — это мощный редактор MD, но даже самые лучшие требуют обновления. В этом посте мы рассмотрели размещение собственного локального экземпляра StackEdit и одновременное развертывание нескольких экземпляров, которые совместно используют данные localStorage. В следующем посте мы внесем изменения в вывод HTML и позаботимся о том, чтобы мы могли настроить блоки кода по своему вкусу. Есть какие-нибудь собственные хаки, которыми можно поделиться? Дайте нам знать!