Вы можете решить это без базы данных, но я бы не рекомендовал это. По сути, у вас есть пары (user, localStorage), и когда данный пользователь идентифицирует себя, его / ее localStorage должны быть предоставлены определенным образом. Вы можете попросить пользователей хранить свои локальные хранилища на своем собственном компьютере, но тогда им придется скопировать его на другие машины, что является трудоемким и никогда не приобретет популярность. Можно вручную запустить блок Javascript в консоли своего браузера, чтобы убедиться, что у localStorage есть свои данные, и копировать localStorage на разных компьютерах лишь немного проще, чем делать все вручную.
Вы можете поместите информацию о localStorage, закодированную в URL-адрес, но помимо проблемы длины URL-адреса, которая может стать проблемой, и постоянных проблем с кодированием, весь ваш localStorage может контролироваться третьей стороной, имеющей доступ к маршрутизатору. Я знаю, что вы сказали, что данные не являются конфиденциальными, но я верю, что они не являются конфиденциальными пока . Но как только пользователи будут использовать это, если это удобно, они также будут хранить конфиденциальные данные, или у ваших клиентов могут быть такие задачи для вас, или даже вы можете понять, что вам нужно хранить там данные, которые не публикуются на 100% c .
Кроме того, на практике вы столкнетесь с очень серьезными проблемами синхронизации, то есть все хорошо, чтобы сделать localStorage agnosti c, но тогда, какова реальная версия? Если вы регулярно работаете над 10 различными сессиями, то синхронизация localStorages становится сложной задачей. Это означает, что localStorage необходимо пометить по времени.
Таким образом, вам потребуется центральное место, сервер для хранения последней сохраненной версии localStorage. Если по каким-то неизвестным причинам вас отвлекли базы данных, вы можете хранить локальные хранилища внутри файлов, которые идентифицируют пользователя, например
johndoe. json
и затем вы потребуется реализовать функцию экспорта, которая будет отправлять текущий JSON пользователя на сервер и сохранять его в файл, а также функцию импорта, которая будет загружать файл, сохраненный для пользователя, и обеспечивать соответствующее обновление localStorage. Вы также можете сделать это вместе, реализовав синхронизацию.
Пока это просто, но что, если у пользователя уже есть некоторые полезные данные внутри его локального локального хранилища, а также на сервере? Самый простой подход - переопределить одно другим, но какой? Если мы импортируем, то локальный переопределяется, если экспортируется, то перезаписывается тот, что на сервере, если мы синхронизируем, то перезаписывается более старый.
Однако в некоторых случаях вы хотите объединить два localStorages того же пользователя, поэтому:
новые элементы
Я считаю, что если элемент новый, то следует каким-то образом знать, что он был создан в этом сеансе, что полезно для знаю, потому что это означает, что на другом сеансе, с которым мы объединяемся, этот новый элемент не был удален, и, следовательно, его можно добавить.
элемент меняет
Если тот же элемент отличается в обоих случаях более новая версия должна иметь преимущественную силу.
удаленные элементы
Интересный случай - когда в одном сеансе он был удален, а в другом - обновлен. В этом случае я думаю, что более новые изменения должны преобладать.
Однако, несмотря на все ваши усилия, пользователи могут все еще испортить (и ваше программное обеспечение тоже) вещи, поэтому резервное копирование каждого сеанса на вашем сервере делает чувство.