Puede resolver esto sin una base de datos, pero no lo recomendaría. Básicamente tiene pares (usuario, localStorage) y cuando un usuario determinado se identifica a sí mismo, su localStorage debe proporcionarse de alguna manera. Puede decirles a los usuarios que almacenen sus almacenes locales en su propia máquina, pero luego tendrán que copiarla en otras máquinas, lo que requiere mucho trabajo y nunca ganará popularidad. Uno podría ejecutar manualmente un fragmento de Javascript en la consola de su navegador para asegurarse de que localStorage tenga sus datos y tener que copiar el localStorage en todas las máquinas es solo un poco más fácil que hacerlo manualmente.
Puede poner la información de localStorage codificada en una URL, pero además del problema de la longitud de la URL, que podría convertirse en un problema y los problemas de codificación siempre presentes, un tercero puede monitorear su localStorage completo, teniendo acceso a su enrutador. Sé que has dicho que los datos no son confidenciales, pero creo que todavía no lo son . Pero una vez que los usuarios usen esto, si es conveniente, también almacenarán datos confidenciales o, sus clientes podrían tener tales tareas para usted, o incluso podría darse cuenta de que necesita almacenar datos allí que no sean 100% públicos.
Además de estos, en la práctica enfrentará problemas muy serios de sincronización, es decir, es bueno hacer que agnóstico localStorage, pero entonces, ¿cuál es la versión real? Si trabaja regularmente en 10 sesiones diferentes, sincronizar localStorages se convierte en un problema difícil. Esto significa que localStorage debe tener una marca de tiempo.
Por lo tanto, necesitará un lugar central, un servidor para almacenar la última versión guardada localStorage. Si las bases de datos lo evitan por razones desconocidas, puede almacenar localStorages dentro de archivos que identifican al usuario, como
johndoe.json
y luego, deberá implementar una función de exportación, que enviará el JSON actual del usuario al servidor y lo guardará en un archivo y una función de importación, que descargará el archivo almacenado para el usuario y garantizará que localStorage se actualice en consecuencia. También puedes hacer los dos juntos, implementando una sincronización.
Esto es simple hasta ahora, pero ¿qué pasa si el usuario ya tiene algunos datos útiles dentro de su localStorage local y también en el servidor? El enfoque más simple es anular uno con otro, pero ¿cuál? Si estamos importando, se anula el local, si se exporta, se anula el del servidor, si sincronizamos, se anula el anterior.
Sin embargo, en algunos casos desea fusionar dos Almacenes locales del mismo usuario, por lo tanto:
nuevos elementos
Creo que si un elemento es nuevo, se debe saber de alguna manera que se creó en esta sesión, lo que es útil saber, porque eso significa que en la otra sesión con la que nos estamos fusionando, este nuevo elemento no se eliminó y por lo tanto, es intuitivo agregarlo.
cambios de elementos
Si el mismo elemento es diferente en los dos casos, entonces prevalecerá la versión más nueva.
elementos eliminados
El caso interesante es cuando en una sesión se eliminó y en la otra se actualizó. En este caso, creo que el cambio más reciente debería prevalecer.
Sin embargo, a pesar de sus mejores esfuerzos, los usuarios aún pueden estropear (y su software también) las cosas, por lo que hacer copias de seguridad de cada sesión en su servidor tiene sentido.