Хабр! Добро пожаловать снова.
Сегодня я расскажу о том как писатели Хабра теряют свои статьи из за ошибок в работе редактора Хабра. Если вы хоть раз сталкивались с тем чтобы опубликовать накопленные знания то вам должна быть известна эта проблема. Мне бы очень хотелось чтобы разработчики Habr и Chromium услышали меня и исправили эту проблему как можно скорее.
localStorage
Эта проблема существует с 2018 года именно тогда я впервые публиковался на Хабре и точно помню что все написаное как тогда так и сейчас хранилось в localStorage — локальное хранилище данных в браузере в виде объекта содержащего строки. Очень просто очищается внезапным сбоем в системе, также неправильным закрытием браузера или любым другим непредсказуемым событием. В целом localStorage это классный инструмент, для хранения мелких и незначительных данных в браузере.
Я считаю что это не правильно, нельзя так разнузданно хранить данные в которые вложены часы. Редактирование и организация которых может продолжаться ни одну неделю или месяц. Бывает так что ты возвращаешься к написанию через несколько дней или недель чтобы дополнить статью, а ее просто нет, ее нельзя восстановить из автосохранения. Каждый раз это лотерея и я лично уже несколько раз попался на эту историю, честно сказать я даже сохранял localStorage в JSON файл чтобы вдруг что-то не потерять и восстановить через консоль браузера, а сейчас и вовсе пишу эту статью в заметках но это не так удобно, потому что потом мне придется пойти еще на Хабр и там все отредактировать и расставить по своим местам.
P.S. Буквально неделю я готовил вторую часть статьи о разработке и публикации расширения для браузера, решил дописать её этим вечером, не дописал.
P.P.S. В комментариях поднялась бурная дискурсия на тему работы localStorage и самого редактора, пришлось придумать как воссоздать баг по крайней мере в Mac OS он получается таким образом:
Заходим в редактор пишем что-то
Переходим в какой-нибудь раздел
Возвращаемся в редактор
Восстанавливаем из автосохранения
Принудительно закрываем браузер (я ничего не трогаю в браузере)
Открываем снова
Переходим в редактор
Автосохранения нет
???
Принудительно закрытый браузер — это имитация любой проблемы с операционной системой, отключения электричества, синий экран, ошибка ядра. То есть можем точно подтвердить что если во время редактирования статьи у нас что-то случилось с браузером скорее всего мы ее потеряем. Обычно когда я выключаю компьютер, у меня все программы закрывают сами, в том числе и браузер где может быть открыта статья.
P.P.P.S. Пришлось провести дополнительное расследование, чтобы понять в чем истинная проблема, сразу скажу что дело не в localStorage и не в периодичности обновления localStorage, а в способе хранения, дело в том что после восстановления статьи из автосохранения ее там больше нет, она вычищается, а по-хорошему её нужно не удалять, а заменять новыми данными если они есть.
С помощью не хитрого кода можно отследить что редактор обновляет localStorage каждый раз после изменения через 3 секунды.
Код
let oldLS = JSON.stringify(localStorage)
setInterval(() => {
const newLS = JSON.stringify(localStorage)
if (newLS !== oldLS) {
oldLS = JSON.stringify(localStorage)
console.log('update localStorage')
}
})Проверить проблему можно просто восстановив из автосохранения и не сделав ни одной правки закрыть ее, после этого сохранения уже не будет.
Хабр, не удаляй автосохранения из localStorage после восстановления статьи.
Комментарии (25)
korsetlr473
16.12.2021 21:48-3Привет, вы наверно назбираетесь , какой сейчас лучший редактор для блога-программиста ?
thegriglat
16.12.2021 22:03+7ed
Loggus66
17.12.2021 01:22+4Computer 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/emacsOf 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!!!
Exclipt
16.12.2021 23:30+6С одной стороны - это конечно косяк, хранить драфт в локалсторадже, а с другой стороны - доверять свой драфт браузеру (и/или порталу в браузере), у которых и без локалстораджа может быть приколов немеряно, - не меньший косяк.
mSnus
17.12.2021 01:39+6С третьей стороны, хочется таки доверять хотя бы сайтам уровня и направленности Хабра, что они самое ценное (пользовательские тексты) будут нормально хранить.
cepera_ang
17.12.2021 06:24+2И вообще, то, что задача сохранить несколько килобайт текста вдруг считается чем-то, что должно требовать доверия — это яркий показатель состояния дел в вебе.
mSnus
17.12.2021 08:23+4Если бы только в вебе.. только что вот Illustrator 2020 отказался открывать файл, который минуту назад сам спокойно сохранил. День работы...
GrayHorse
17.12.2021 06:44+4Очень просто очищается внезапным сбоем в системе, также неправильным закрытием браузера или любым другим непредсказуемым событием.
Вы проводили эксперименты с этим или это такое субъективное мнение?
Лично я активно использую LocalStorage в своих юзер скриптах и данные у меня ни разу не пропадали сами по себе, несмотря ни на внезапные закрытия браузера из-за нехватки оперативной памяти, или из-за отключения электричества, или если я не заходил на сайт несколько месяцев. Максимум, если браузер крашнулся во время активной записи в LS, после перезапуска браузера в LS было состояние за не сколько секунд до краша.Теоретически браузер сам может очистить данные при нехватке памяти в рамках Eviction Policy [1][2], но для этого, судя по всему, нужно, чтобы системный диск был конкретно так забит.
У меня есть подозрения, что статьи были утеряны из-за самой логики работы восстановления драфта на Хабре: ибо при восстановлении статьи из драфта, драфт удаляется из LS. И если закрыть/перезагрузить вкладку не внеся какого-либо изменения, чтобы драфт вновь добавился в LS, статья будет утеряна. Но при чем тут LocalStorage? При таком принципе работы какое хранилище не используй, результат будет один и тот же.
prohetamine Автор
17.12.2021 07:03+1Да я проводил эксперименты, если взять localStorage и скажем присвоить ключ
number, что будет выглядеть какlocalStorage.number = 2и затем следом создать цикл и сделать его вечным пусть будет for, а уже в нем перезаписывать ключnumberв localStorage черезMath.random()и выводить или не выводить его в консоль (не так важно) и завершить браузер в моем случае это делается на MacOS через «Принудительное завершение программ» то после открытия браузера на том же сайте где проходил эксперимент в localStorage будетnumberc значением установленным до цикла то есть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
extempl
17.12.2021 09:03+4Но подождите, ведь последнее нормальное значение останется! Точно так же как хранить на сервере и в последнем запросе на сохранение выключить роутер - при следующей загрузке данных вы получите последнее сохранённое значение. Что вполне нормально и ожидаемо и ничего с этим не поделаешь.
Бесконечный синхронный цикл – не показатель. Обычно оно так не работает (а если работает, потому что кто-то пропихнул такое в продакшен – то ломается обычно довольно громко и от того быстро чинится). Но так же можно сломать и запись на сервер и много ещё чего можно сломать. При этом, запись в LS сильно быстрее, чем любая другая запись и состоит из меньшего кол-ва бутылочных горлышек (мест где что-то может пойти не так), соответственно, риск что у вас что-то там произойдёт именно в момент записи - минимальный (быстрее запись - меньше промежуток времени когда оно должно сломаться чтоб испортить запись), не говоря уже о том, что это делается с определённой периодичностью и предыдущее значение восстановится.
Как уже отметил @GrayHorse выше – localStorage сам по себе не очищается, даже когда вы чистите куки-историю и прочее. Разве что вы не используете отдельное расширение или приложение (может CleanMyMac/PC (хотя не уверен что оно тоже чистит)) чтоб периодически очищать localStorage – тут уж вы ССЗБ.
P.S. Если у вас не сохраняется черновик, например при редактировании и перезагрузке вкладки периодически - это скорее повод обратиться в ТП.
vadim5june
17.12.2021 21:37Сам по себе localStorage надежно сохраняет данные, и проблема не в нем.
Ваш пример не правильный(не понимаете как работает javascript), правильно сделать цикл например с помощью setInterval, тогда получите рандомное значение
Adler_lug
17.12.2021 09:15+6После того, как на различных ресурсах по разном причинам терялся набираемый на протяжении некоторого времени текст, для себя выработал привычку, что если собираюсь набрать какой бы то небыло объемный размер текста, то набираю его сперва в блокноте, а в редакторе его лишь форматирую.
Уже ни раз данная привычка уберегала от потери набранного текста.
OlegApp
18.12.2021 17:10Это отличная привычка) У меня пока не получается до автоматизма ее довести, так что временами взрываюсь, когда вижу, что текст не сохранился
dartraiden
19.12.2021 01:25Я эту проблему решил дополнением в браузере. FormSave (Firefox), Typio Form Recovery (Chrome) и т.п.
unfriend
17.12.2021 12:32-1На мой взгляд, это не баг Хабра, а ваш фичареквест к его разработчикам. Потому что хранить и обрабатывать драфты не в localStorage, а где-то на сервере — это доп. задача и доп. затраты на реализацию/поддержку/правку багов.
За себя могу сказать лишь, что в подобных случаях меня выручает менеджер буфера обмена + привычка большие/важные тексты копировать перед любой отправкой на сервер (и даже перед переключением в режим превью). Спасает даже в таких случаях, когда, казалось бы, всё хорошо, но текст на время отправки становится disabled (и без своевременного погружения в девтулзы его уже не скопировать), а сервер падает с какой-либо ошибкой (скажем, вы в метро, и сообщение по таймауту не успело отправиться).
:)
phanerozoi_evidence
К сожалению была и у меня такая проблема, но она решалась написанием основного текста в гугл-документе. Почему бы и Вам не попробовать?
prohetamine Автор
Да это безусловно выход, но проблема существует и ее нужно заметить, это же не игра где мы получаем случайный результат, данные должны храниться надежно если нам это обещает редактор иначе зачем обещает.. Я думаю что эта функция или должна быть и работать или ее должно не быть в таком случае если она работает не стабильно.
Lexicon
Было бы круто если бы у хабра была прозрачная позиция на этот счет, могли бы вообще удалить редактор и оставить ссылку на драйв, если так сложно сделать редактор
Как удобно! И версирование будет, и обновлять статью легко, и даже коллаборироваться.
prohetamine Автор
На самом деле редактор дествительно сложно сделать, я щас делаю для себя что-то вроде редатора) А что за драйв ?
Lexicon
гугл драйв
Я делал редактор для издательства, это сложно когда от вас действительно требуется создать нечто уникальное, а статьи пишут домохозяйки.
Но хабр всё же айти ресурс, здесь пользователи знают, чего хотят. Они видели редактор медиума, знают markdown, знакомы с LaTex и html структурами, а потому
Предсказуемость и гибкость инструмента важнее его вида и простоты
Vitaly83vvp
Я ни разу не позционировал редактор на сайте как хранилище данных. То, что текст хранится в localStorage, скорее, приятный бонус, а не возможность хранить данные. Как уже писали здесь, Google Документы тут, как нельзя лучше, подходят. Кроме того, у них есть режим offline работы. Кроме того, в документах можно хранить данные в нужной структуре. И с версиями. А сюда выкладывать уже готовый вариант.
prohetamine Автор
Хорошо, в таком случае я попробую написать следующую статью в гугл докс, она как раз получится объемной и у меня будет возможность поделиться впечатлениями.