Comments 8
setLocalStorageItem
Зачем возвращать всегда null из метода?
Если isNil вернёт true, а isUndefined- false, то дважды вызовется запись в localStorage.
У кода вложенность уменьшить бы, я б инвертнул условия.
Как предлагаете использовать ваше решение, копипастить? Если, вдруг, кто то захочет.
Ну и напоследок,
В рамках своей работы, я не раз сталкивался с проблемой, что нужно отслеживать изменение в LocalStorage в совершенно независимых компонентах
Мне кажется, что то делаете не так. LocalStorage не для этого, шарьте данные сервисами или чем там принято в каждом конкретном фреймворке. А storage уже юзайте для коммуникации между вкладками
Массив который содержит ключи в localStorage, при изменении значений которых будет вызываться функция обработчик
Долго втыкал в код, если передать пустой массив - то это подписка на изменение любых ключей будет?
Какие проблемы решает хук useLocalStorageEffect
У вас в этом блоке ни одной проблемы не указано.
Отслеживание изменений происходит в любом месте вашего приложения
Проблема то в чем?
Вам не обязательно волноваться о перезагрузке вашей страницы, для того что бы информация обновилась
В чем проблема?
Код выглядит лаконично и понятно
В чем проблема то?
Все три пункта высосаны из пальца
Обратите внимание, это код мидл-фронта, который хочет 200к. Не джуна.
Я в целом не понимаю столь большую любовь к LocalStorage.
Это безусловно нужная вещь, но лишь в определенных местах. В большинстве случаев можно обойтись возможностями фреймворка (включая хранилище) и EventBus-ом.
Не припомню на своем опыте, чтобы приходилось изобретать велосипед для LocalStorage. Причем даже в больших проектах. Всегда хватало стандартного JS API.
Учитывая декларативный подход реакта, логичнее было бы иметь хук useLocalStorageData, который возвращает значение указанного ключа, и вызывает рендер, когда оно изменилось.
P.S. Без lodash здесь можно вполне обойтись. Он только усложняет понимание материала.
В рамках своей работы, я не раз сталкивался с проблемой, что нужно отслеживать изменение в LocalStorage в совершенно независимых компонентах.
Где-то что-то не так с логикой, причинами и следствиями.
- Из LocalStorage достаточно только прочитать один раз во время инициализации стартового состояния.
- При обновлении состояния - как сайд-эффект обновлять и LocalStorage (если это действительно надо).
- Источником истины для обновления компонентов должно быть состояние, а не LocalStorage.
Если неудобно шарить состояние между компонентами - mobx в помощь))
Мне кажется, статья про реализацию конкретного механизма, а не про то, какой способ хранения состояния лучше.
Но раз зашла речь про сравнение способов, то вот мои 3 копейки. Я согласен, что в большинстве случает лучше делать синхронизацию через JS-память. Но есть ситуации, когда это костыльно или невозможно. Например, HTML-виджеты, которые вставляются на сторонние сайты, особенно если они iframe. Конечно, в JS есть механизмы, предназначенные именно для синхронизации между вкладками и фреймами. Но раз localStorage предоставляет одновременно синхронизацию и сохранение данных минимумом кода, а объём данных не большой, то почему бы нет?
в реакт 18 появился useSyncExternalStore - хук для работы с внешними хранилищами. Без него будут проблема с SSR
Хорошо, а какой кейс применения? Почему не просто через воркер, как все нормальные люди? Чем данная реализация лучше?
Пишем свой хук для отслеживания изменений в LocalStorage