Blog / Web / Almacenar preferencias de usuario I: local
Hay que distinguir primero entre la configuración asociada
a la cuenta del usuario o sus preferencias, que sólo debe afectar
al propio usuario y la configuración para la aplicación,
que afectará a todos los usuarios de la misma y debería, poder
ser modificada sólo si se dispone de permisos para ello.
Las preferencias del usuario pueden "gravarse"
de distintas formas, ya sea en el navegador, la sesión del usuario,
la BD de la aplicación, asociándolas al mismo usuario, etc.
Guardar preferencias de forma local o en el navegador
El mecanismo, posiblemente, más simple para guardar "preferencias" de
un usuario en un navegador es el Local Storage y es válido siempre
que lo que guardemos no afecte a la privacidad/seguridad del sistema
y no sea tedioso establecer nuevamente las preferencias si se pierden.
Hay otros mecanismos disponibles en el navegador para almacenar preferencias,
el resultado final es similar al del Local Storage.
En cualquier caso, estas preferencias deberían afectar SÓLO a como se ven
los datos ya descargados, si se usan en acciones que afectan al servidor,
habría que añadir parámetros o información adicional en las peticiones
lo que hace más sencillo optar por otro método.
Ejemplo de almacenamiento de preferencias local
Escenario
- La aplicación dispone de varias paletas de colores.
- Un usuario visualiza tablas con información desde un único dispositivo.
- Las tablas pueden mostrarse en varias páginas con cierto número de registros por página.
Historias de usuario
- El usuario puede elegir la paleta de colores de su espacio de trabajo.
- El usuario puede elegir el número de registros de las tablas
que verá en cada página.
Soluciones
Guardar la paleta de colores seleccionada en local en una buena opción,
sólo requerimos una clave (key) y un valor, por ejemplo:
{
key : color_palette,
value: dark
}
NOTA: Si el usuario pudiera acceder desde distintos dispositivos
y tuviera que mantener la configuración en cada uno de ellos,
el almacenamiento local de esta preferencia ya no sería válido.
Guardar el número de registros que se quiere ver por página en las tablas
debería hacerse en el servidor, si lo hacemos en local, habrá que añadir
ese número en cada petición asociada a cada tabla,
esto sería aún peor si se permite seleccionar un número de registros para
cada una de las tablas del sistema.
Programación del almacenamiento de preferencias en local
Voy a dar sólo unos apuntes...
Cuando almaceno "cosas" en el Local Storage con JavaScript uso una clase
que agrupa varios métodos y abstrae el API Local/Session Storage del navegador,
mi clase Storage incluye los métodos:
clear() // void
get(key) // mixed
has(key) // bool
set(key, value) // void
unset(key) // void
además de un constructor que establece el uso por defecto del objeto
window.localStorage o permite usar window.sessionStorage
si se le pasa como parámetro el string 'session'.
Al ver la instancia de la clase en el código se puede pensar que se trabaja
sobre el almacenamiento local o de sesión del navegador, para poder
relacionar el uso de un objeto con un uso específico como
"almacenar preferencias de usuario" de la aplicación puede implementarse
una clase que extienda a Storage, por ejemplo:
class UserPreferences extends Storage // class
{
constructor(storageMechanisms = 'local') // construct
{
super(storageMechanisms);
}
}
const userPreferences = new UserPreferences();
Ahora, si vemos la línea userPreferences.clear();
podemos intuir que la acción se relaciona con el borrado de las preferencias
del usuario, si bien, ahora mismo esta llamada borra todo el contenido del
LocalStorage.
En la clase UserPreferences podemos incluir también las llaves de las
preferencias del usuario y usarlas al almacenar las mismas.
Ahora, deberíamos sobrescribir el método clear para que borre sólo
esas llaves del storage
(ejemplo completo en el post:
POO en VainillaJs II: instancias y herencia
).
10-09-2024
