Он может банально через инструменты разработчика изменить сохраненный json и сделать его невалидным.

destus,
и многих вы рядовых пользователей знаете которые через инструменты разработчиков правят json ???)))))

destus,
ничего не имею против, хочется увидеть именно сногсбивающую аргументацию...)))

destus,
касательно архитектуры что скажите?? господа вам не кажется что когда в задании вас просят

Задача: отрефактировать код без использования сторонних библиотек.
Исправить баги, улучшить качество, maintainability, читабельность.
CSS писать не нужно.

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

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

ну а кто мне минус кармы дал то отпишите аргументы...

Смысл в том, что нужно предусмотреть все возможные ситуации, и грамотно их обрабатывать. Это может быть json с нашего сервера, со стороннего апи. Не важно. Что более важно, так это написать гибкое приложение, которое будет обрабатывать по-возможности все возможные ошибки и грамотно на них реагировать. JSON.parse, как и обращение к localStorage всегда с try...catch.
Далее, у вас не получился компонент как таковой.
Во-первых, он наследуется от модели, что является очень плохим решением.
Во-вторых, компонент должен получать кусок состояния через биндинги сверху и отрисовывать UI. Это если мы говорим о stateless компонентах. Для statefull - источником данных могут быть сервисы. Под капотом взаимодействие с DOM событиями, но опять же, компонент сам не меняет состояние. Нужно либо генерировать событие и просить это сделать внешний код (EventEmitter), либо просить это сделать сервисы, складывая всю ответственность на них.
Ну и в-третьих, в коде есть баги. Если, например, открыть несколько записей для редактирования, и нажать Save / Remove по любой из них, то все открытые записи выйдут из режима редактирования.

Можете объяснить почему?
Если обернуть взаимодействие с localStorage в класс, который будет проверять доступно ли оно или нет и преобразовывать все данные в строку перед записью, то есть ли смысл оборачивать localStorage во wrapper'е в try catch?

Nexus,
https://developer.mozilla.org/en-US/...eb_Storage_API
пункт "Testing for availability".
скорее в функцию, которая проверяет доступность хранилища.

destus,
благодарю за информацию.
Можно, конечно, в коде постоянно проверять доступно ли хранилище, но, по-моему, удобнее реализовать класс.

Nexus,
Можете и через класс, но просто проверить доступно оно или нет, этого мало. Установка нового значения может упереться в отсутствие памяти и выбросом исключения QuotaExceededError https://www.w3.org/TR/webstorage/#storage

destus, я понял, что доступность хранилища не гарантирует корректного с ним взаимодействия.