Localstorage explorer
 

Делали тут одну игрушку и понадобилось сохранять статус и уровень, чтоб после перезагрузки не начинать сначала. Ну и решили в localStorage сохранять. Но как дебажить? Оно же всё время записывает данные и потом начинает откуда-то не сначала! Нужно что-то типа эксплорера, чтоб ненужное удалять. Иду искать в гугл, и...ничего! Ну не то чтобы совсем ничего, есть расширения для браузеров, но это нужно для каждого браузера, да и под мобильные не будет, а нам надо на мобильном тоже. Был ещё еле еле рабочий скриптик, не буду его пиарить, можете сами по названию поискать, он примерно так и называется.

Ну, в общем, не долго думая, сажусь писать свой велосипед (или не велосипед?) и вот что получилось.

Вот тут скрипт на gist одним файлом (не считая зависимости w3.css):

https://gist.github.com/yesasha/5e8a...b0d8459c7fd616. Если нужно в свой проект этот файл кидаем в папку и испоьзуем.

Вот тут можно на codepen поиграться https://codepen.io/yesasha/pen/ppdyWL. За одно увидите что другие проекты от codepen хранят в вашем localStorage.

Немного поясню как оно работает.

• Решил использовать таблицу, так как по моему мнению для таких данных таблица в самый раз, тем более я планировал её сортировать по разным столбцам.
• Выглядит она так как выглядит, потому что вот https://www.w3schools.com/w3css/w3css_tables.asp.
• Первый столбец это индекс. Это то в каком порядке записи находятся в localStarage. Во всяком случае в таком порядке браузер проходит по значениям при переборе. Это зависит от браузера, но может быть полезно это видеть.
• Второй столбец - это ключ, третий - значение. Числа сортируются как числа, строки как строки. Есть функция isNumeric, взятая с этого сайта, чтобы отличить числа от строк.
• При добавлении/удалении ключей, копируем содержимое в новый массив, потом сортируем его одной из 6 возможных функций (3 столбца, по 2 на каждый: убывание/возрастание). Потом обновляем таблицу, сравнивая старый массив с новым. Обновляем только изменившиеся значения. Не гарантирую, что данный подход самый хороший, но сделал так. По аналогии с virtual DOM. Кстати, массив не мутирует, а создаётся новый - аналогия с immutable state в redux. Но это пока всё.
• При клике на заголовки происходит сортировка и таблица обновляется.

Добавлю новые фичи если будет интерес к проекту. Так же жду вашу критику.

Я хоть и не middle/senior js, однако вставлю свои 5 копеек.

Обработка нажатий на определенные элементы таблицы интересно сделана.
Я бы, как минимум, вынес выполнение операций (удаление, добавление и .т.п.) в отдельные функции и избавился от повторения одного и того же кода.

Не проверяется доступен ли элемент коллекции под определенным ключом или нет.
Взаимодействие с локальным хранилищем осуществляется без проверки его доступности + вне try catch.

Функция "removeAllSortingClasses" и 6 функций "sort[\d]" вызвали пару вопросов:
1. Почему в "removeAllSortingClasses" не воспользовались циклами?
2. Зачем N функций, если их отличия минимальны, почему не 1 с несколькими агрументами для управления поведением?

Заранее прошу прощения, но я бы не стал пользоваться Вашим решением, много Индусского кода.

Я вот тоже подумал, что индусский код, хоть и рабочий, может магическим образом оттолкнуть пользователей...
Код был ещё более индусским, но в определённый момент хочется сказать и так сойдёт. Благодаря же Вашим замечаниям провёл рефакторинг, узнал некоторые новые вещи, например про навигацию по таблице. Многие функции объединились. От многих избавился. Теперь состояние просто хранится в глобальных переменных. Теперь содержимое localStorage перечитывается и при сортировке. Более того, это помогло всё убрать в одну функцию рендеринга.

А что именно интересного в обработке нажатий?

LocalStorage не выбрасывает исключений. И ничего страшного не происходит, если удалить элемент дважды. С classList тоже самое. Какие ещё коллекции не проверяются?

Обновил версии по ссылкам, теперь там новые версии. Старую же прикрепил сюда для сравнения.

Почитайте
Все сценарии были в одном методе, плохо читается + было ненужное повторение в коде.

Не особо разбирался в вашем коде, но более чем уверен, что строки 93-111 можно сократить.

} else if (classList.contains('index') && !classList.contains('asc') && !classList.contains('dsc')) {
    render(0, 'asc');
  } else if (classList.contains('key') && !classList.contains('asc') && !classList.contains('dsc')) {
    render(1, 'asc');
  } else if (classList.contains('value') && !classList.contains('asc') && !classList.contains('dsc')) {
    render(2, 'asc');
  } else if (classList.contains('index') && !classList.contains('asc') && classList.contains('dsc')) {
    render(0, 'asc');
  } else if (classList.contains('key') && !classList.contains('asc') && classList.contains('dsc')) {
    render(1, 'asc');
  } else if (classList.contains('value') && !classList.contains('asc') && classList.contains('dsc')) {
    render(2, 'asc');
  } else if (classList.contains('index') && classList.contains('asc') && !classList.contains('dsc')) {
    render(0, 'dsc');
  } else if (classList.contains('key') && classList.contains('asc') && !classList.contains('dsc')) {
    render(1, 'dsc');
  } else if (classList.contains('value') && classList.contains('asc') && !classList.contains('dsc')) {
    render(2, 'dsc');
  }

Те строчки действительно получилось сократить и очень сильно. Но вот стоило ли оно того? Ведь было потрачено время, а оно и так работало!

Насчёт доступности хранилища, замечание полезное. Добавил проверку доступности в функцию рендеринга. Не уверен насчёт полезности данного подхода.

Плюс добавил ещё несколько полезных вещей.
Например фокус возвращается на поле ввода после клика по кнопке, что позволяет быстрее добавлять новые записи.
В панели статуса отображается доступность хранилища и кол-во записей.

Ну-с, даже не знаю как прокомментировать. С таким мнением можно было оставить и первоначальную версию вашего творения, она же работала.

Ну, некоторые изменения были важны, например проверка доступности. Странно, что я не замечал ту статью.
А на остальное нет однозначного ответа для всех. Это каждый для себя должен ответить, в зависимости от того кем он хочет стать! Программистом или кодописцем)
Но в целом если код более понятен, то потом проще выявить баги и добавлять новые функции. Понятен, не значит меньше кода, а то писал я тут букмарклет...

Yesasha, если код недостаточно ясен для понимания, в любом яп есть такая вещь, как комментарии, которые эту неясно могут легко исключить.

Никого до вас не встречал, кто бы говорил, что Индусский стиль написания кода улучшает его общую понятность и скорость написания.
Глупость, имхо.

Поддерживать такой код еще то удовольствие...

А я не говорил что индусский стиль улучшает! Я сказал, что мне удалось сократить код и он СТАЛ понятнее. Но я мог его не сокращать и оставить как есть, если бы решил, что оно того не стоит, в смысле тратить время на проект, который никому не нужен, к примеру. Более того, я не видел изначально, что получится сократить на столько! А индусский стиль не столько понятен, сколько он сам по себе возникает, когда добавляешь много новых функций, просто дописывая новый код, не ориентируясь на уже написанный. А потом, есть такая вещь, как рефакторинг, как раз для того, чтобы взглянуть со стороны и переписать по другому. И вряд ли можно всегда сразу писать идеально.

Нужно стараться к этому стремиться :)