Комментарии 25
К сожалению была и у меня такая проблема, но она решалась написанием основного текста в гугл-документе. Почему бы и Вам не попробовать?
Да это безусловно выход, но проблема существует и ее нужно заметить, это же не игра где мы получаем случайный результат, данные должны храниться надежно если нам это обещает редактор иначе зачем обещает.. Я думаю что эта функция или должна быть и работать или ее должно не быть в таком случае если она работает не стабильно.
Было бы круто если бы у хабра была прозрачная позиция на этот счет, могли бы вообще удалить редактор и оставить ссылку на драйв, если так сложно сделать редактор
Как удобно! И версирование будет, и обновлять статью легко, и даже коллаборироваться.
На самом деле редактор дествительно сложно сделать, я щас делаю для себя что-то вроде редатора) А что за драйв ?
гугл драйв
Я делал редактор для издательства, это сложно когда от вас действительно требуется создать нечто уникальное, а статьи пишут домохозяйки.
Но хабр всё же айти ресурс, здесь пользователи знают, чего хотят. Они видели редактор медиума, знают markdown, знакомы с LaTex и html структурами, а потому
function over form
Предсказуемость и гибкость инструмента важнее его вида и простоты
Я ни разу не позционировал редактор на сайте как хранилище данных. То, что текст хранится в localStorage, скорее, приятный бонус, а не возможность хранить данные. Как уже писали здесь, Google Документы тут, как нельзя лучше, подходят. Кроме того, у них есть режим offline работы. Кроме того, в документах можно хранить данные в нужной структуре. И с версиями. А сюда выкладывать уже готовый вариант.
Есть же сохранение в черновики…
Привет, вы наверно назбираетесь , какой сейчас лучший редактор для блога-программиста ?
ed
Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
Of course, on the system I administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can remember what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
Markdown-плагин для его редактора кода/IDE?
С одной стороны - это конечно косяк, хранить драфт в локалсторадже, а с другой стороны - доверять свой драфт браузеру (и/или порталу в браузере), у которых и без локалстораджа может быть приколов немеряно, - не меньший косяк.
Очень просто очищается внезапным сбоем в системе, также неправильным закрытием браузера или любым другим непредсказуемым событием.
Вы проводили эксперименты с этим или это такое субъективное мнение?
Лично я активно использую LocalStorage в своих юзер скриптах и данные у меня ни разу не пропадали сами по себе, несмотря ни на внезапные закрытия браузера из-за нехватки оперативной памяти, или из-за отключения электричества, или если я не заходил на сайт несколько месяцев. Максимум, если браузер крашнулся во время активной записи в LS, после перезапуска браузера в LS было состояние за не сколько секунд до краша.
Теоретически браузер сам может очистить данные при нехватке памяти в рамках Eviction Policy [1][2], но для этого, судя по всему, нужно, чтобы системный диск был конкретно так забит.
У меня есть подозрения, что статьи были утеряны из-за самой логики работы восстановления драфта на Хабре: ибо при восстановлении статьи из драфта, драфт удаляется из LS. И если закрыть/перезагрузить вкладку не внеся какого-либо изменения, чтобы драфт вновь добавился в LS, статья будет утеряна. Но при чем тут LocalStorage? При таком принципе работы какое хранилище не используй, результат будет один и тот же.
Да я проводил эксперименты, если взять localStorage и скажем присвоить ключ number, что будет выглядеть как localStorage.number = 2 и затем следом создать цикл и сделать его вечным пусть будет for, а уже в нем перезаписывать ключ number в localStorage через Math.random() и выводить или не выводить его в консоль (не так важно) и завершить браузер в моем случае это делается на MacOS через «Принудительное завершение программ» то после открытия браузера на том же сайте где проходил эксперимент в localStorage будет number c значением установленным до цикла то есть 2
До открытия:
localStorage.number = 2
console.log(localStorage.number) // "2"
for (;;) {
localStorage.number = Math.random()
console.log(localStorage.number) // 0.xxxxxxxxxxxxxxxxxx
}
// закрываем браузерПосле закрытия:
console.log(localStorage.number) // "2"Из этого следует что если в момент записи по какой либо причине у нас будет проблема с электричеством, другой сбой в работе chrome или OS мы потеряем последние записанные данные.
Может быть есть еще какие-то не задокументированные проблемы с localStorage которые как раз и приводят к тому что данные исчезают, но это не так важно, у нас есть проблема которая так или иначе случается время от времени, я думаю что не у меня одного, один из комментаторов в начале ветки также подтвердил что такая ситуация бывает.
P. S. Только что запустил и проверил, получил даже не 2 в итоге а undefined.
P. P. S. Снова получил 2
Но подождите, ведь последнее нормальное значение останется! Точно так же как хранить на сервере и в последнем запросе на сохранение выключить роутер - при следующей загрузке данных вы получите последнее сохранённое значение. Что вполне нормально и ожидаемо и ничего с этим не поделаешь.
Бесконечный синхронный цикл – не показатель. Обычно оно так не работает (а если работает, потому что кто-то пропихнул такое в продакшен – то ломается обычно довольно громко и от того быстро чинится). Но так же можно сломать и запись на сервер и много ещё чего можно сломать. При этом, запись в LS сильно быстрее, чем любая другая запись и состоит из меньшего кол-ва бутылочных горлышек (мест где что-то может пойти не так), соответственно, риск что у вас что-то там произойдёт именно в момент записи - минимальный (быстрее запись - меньше промежуток времени когда оно должно сломаться чтоб испортить запись), не говоря уже о том, что это делается с определённой периодичностью и предыдущее значение восстановится.
Как уже отметил @GrayHorse выше – localStorage сам по себе не очищается, даже когда вы чистите куки-историю и прочее. Разве что вы не используете отдельное расширение или приложение (может CleanMyMac/PC (хотя не уверен что оно тоже чистит)) чтоб периодически очищать localStorage – тут уж вы ССЗБ.
P.S. Если у вас не сохраняется черновик, например при редактировании и перезагрузке вкладки периодически - это скорее повод обратиться в ТП.
Сам по себе localStorage надежно сохраняет данные, и проблема не в нем.
Ваш пример не правильный(не понимаете как работает javascript), правильно сделать цикл например с помощью setInterval, тогда получите рандомное значение
После того, как на различных ресурсах по разном причинам терялся набираемый на протяжении некоторого времени текст, для себя выработал привычку, что если собираюсь набрать какой бы то небыло объемный размер текста, то набираю его сперва в блокноте, а в редакторе его лишь форматирую.
Уже ни раз данная привычка уберегала от потери набранного текста.
На мой взгляд, это не баг Хабра, а ваш фичареквест к его разработчикам. Потому что хранить и обрабатывать драфты не в localStorage, а где-то на сервере — это доп. задача и доп. затраты на реализацию/поддержку/правку багов.
За себя могу сказать лишь, что в подобных случаях меня выручает менеджер буфера обмена + привычка большие/важные тексты копировать перед любой отправкой на сервер (и даже перед переключением в режим превью). Спасает даже в таких случаях, когда, казалось бы, всё хорошо, но текст на время отправки становится disabled (и без своевременного погружения в девтулзы его уже не скопировать), а сервер падает с какой-либо ошибкой (скажем, вы в метро, и сообщение по таймауту не успело отправиться).
:)
Хабр, не делай больно писателям