VladimirSchneider 2 фев 2019 в 23:17

Сохранения данных пользователя после перезагрузки страницы

3 мин

13K

JavaScript*

Из песочницы

Комментарии 14

baxxter 3 фев 2019 в 00:33

if (savedTokens != null)
Используйте лучше строгое сравнение и вот почему — dorey.github.io/JavaScript-Equality-Table

data.input == 'true' ? 'checked' : ''
Здесь ошибка(сравниваете булево со строкой), проще сделать так
data.input ? 'checked' : ''

Так же Вы выбрали не очень удобную структуру данных для хранения данных задач(строки), лучше было бы использовать массив объектов и использовать всего один ключ в localStorage, вообще без возни с генерацией токенов(ID?):

localStorage.setItem(`tasks`, JSON.stringify([ {a:1,b:2},{a:2, b:4}]));
JSON.parse(localStorage.getItem(`tasks`));
console.log(...JSON.parse(localStorage.getItem(`tasks`)));
// {a: 1, b: 2} {a: 2, b: 4}

Кстати вот несколько идей, как можно улучшить ваш todo-list: добавить возможность удалять задачи(крестик справа от задачи например), добавить инпут слева от кнопки New Task и генерировать текст новой задачи из данных в нем (сбрасывать ввод после добавления задачи), по чекбоксу слева от задачи зачеркивать текст задачи (статус выполнено), добавить в шапке количество задач (общее, выполнено, не выполнено), добавить возможность указывать срок выполнения задачи (опционально, например дату и время к которой задача должна быть выполнена) и подсвечивать не выполненные в срок задачи красным цветом.

Удачи в изучении Javascript!

JustDont 3 фев 2019 в 01:05

Используйте лучше строгое сравнение

Того, кто пытается использовать строгое сравнение для null — нужно долго бить канделябрами по голове до полного просветления. Пока не поймёт, что ничего принципиально страшного в сравнении с приведением типов нет, а писать (x === null || x === undefined) — удел не очень умных, но очень принципиальных людей.

-4

baxxter 3 фев 2019 в 01:39

Согласен, при условии что Вы понимаете что делаете. Лично я считаю что явное, лучше чем неявное. Кому то ваш код возможно потом еще читать придется :)

vintage 3 фев 2019 в 09:32

А строки вы тоже явно сравниваете через цикл посимвольно?

-6

Zibx 3 фев 2019 в 07:51

Ещё лучше — следить за данными. Раньше использовал undefined, причём в виде void 0 чтоб кто-нибудь его случайно не переопределил, а теперь полностью исключил ситуации внезапно появляющихся ключей и никак не нарадуюсь.

dom1n1k 3 фев 2019 в 13:34

И всё-таки лучше писать ===. Это если исходить из реалий, а не абстрактной теории.
Даже если человек, написавший (x == null), абсолютно четко понимал, как это работает — у человека, читающего сей код через год, не может быть в этом уверенности. У него нет 100% гарантий, что предшественник действительно сделал это сознательно, а не по недосмотру. А значит, для устранения сомнений нужно больше тратить времени на изучение кода.
Это тот самый случай, когда явное действительно лучше, чем неявное.

JustDont 3 фев 2019 в 13:43

Я тут пожалуй присоединюсь к vintage, и скажу, что если продолжать линию рассуждений «как бы чего не вышло» — станет ясно, что писать, например, .map() тоже нельзя. Только перебор элементов в цикле for со счётчиком. А то вдруг читающий не поймёт™.
Да и вообще в пределе окажется, что писать нужно только словами и на бумаге. А то напридумывают этих ваших сложностей, языки, компуктеры, ничего не понятно!

ЗЫ: «Исходя из реалий» ситуация очень проста: JS — уникален в части создания сложностей на ровном месте со своими null и undefined, где null !== undefined. Поэтому код, пытающийся эту «фичу» использовать — не должен проходить в прод, за исключением каких-то совершенно фантастических случаев, когда без этого вообще никак невозможно. А если у нас нет кода, который обрабатывает null и undefined по-разному — то далее везде мы спокойно пишем == null и != null, и это работает.
В случаях других сравнений — можете делать что угодно, хоть везде === насаждать, хоть нет. Это типичная bike shed problem, которую пытаются обсуждать в сотни раз больше, чем она того стоит.

vintage 3 фев 2019 в 19:12

Ну а там, где написано === null точно так же придётся потратить дополнительное время, чтобы убедиться, что человек не забыл сравнить с undefined. А там, где написано === null || === undefined нужно потратить дополнительное время, чтобы убедиться, что человек не написал эту конструкцию на автомате по привычке и тут действительно нужна одна ветка логики для обоих случаев. Вообще говоря, если у вас есть сомнения, что предшественник понимал, что делает, то вам в любом случае придётся потратить время на анализ всех вариантов входного значения.

DarthVictor 3 фев 2019 в 12:26

Не строгое сравнение с null — распространенный кейс. В ESLint например для этого есть отдельная настройка eslint.org/docs/rules/eqeqeq#smart, которая включена в наиболее часто наследуемом конфиге eslint-config-airbnb github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb-base/rules/best-practices.js#L40
Строгое сравнение с null при этом делается, когда вам нужно исключить из сравнения undefined, а это крайне редкий кейс.

JustDont 3 фев 2019 в 13:27

Строгое сравнение с null при этом делается, когда вам нужно исключить из сравнения undefined, а это крайне редкий кейс.

Я бы даже сказал, что если у вас возникает ситуация, когда нужно разделить null и undefined — то стоит переписать код так, чтоб она больше не возникала. Ничего хорошего из кода, который по-разному обрабатывает null и undefined обычно не появляется. Хотя бы потому, что при контакте с любым другим окружением помимо JS у вас немедленно появятся проблемы конверсии этих чудо-данных, где через null и undefined обозначены две разные вещи.