Comments 7
Гугл не рекомендует хранить сложные, разветвленные объекты в IndexedDB, поскольку при записи объекта в хранилище создается полный клон, что может сказываться на производительности. По крайней мере для динамичных программ, сохранение анимированной сцены в IndexedDB было бы нерационально.
Фронтендерам привезли транзакции, а ни относятся к ним, как к кокой-то формальности, которую надо обернуть в красивый апи, который сломает вам приложение.
Веб хранилища потому и синхронные, что вы можете прочитать что-то из них, записать и быть уверенными, что никто не встрянет со своей записью на пол пути, которую вы затрёте. И то, событие изменения веб хранилища отрабатывает асинхронно.
С асинхронным апи уже так не выйдет. Там надо в рамках одной мутирующей транзакции прочитать данные, изменить и записать. А не как в статье - отдельной транзакцией читаем, отдельной пишем.
Мутирующие транзакции выстраиваются в очередь, что позволяет им не конфликтовать даже если они выполняются в разных вкладках. Реализация же в статье будет терять данные, если открыть приложение в 2 вкладках.
Ну и нельзя не упомянуть более толковую статически типизированную обёртку над IndexedDB - $mol_db, которая автоматически применяет недостающие миграции.
Для лёгкого старта с indexedDB рекомендую библиотеку dexie.js , несколько лет использую в production , все отлично.
Ещё большой плюс indexedDB её доступность из веб и сервис воркеров в отличии от localStorage
Как использовать IndexDB для управления состоянием в JavaScript