#Best practice for saving UI preferences in web app?

1 messages · Page 1 of 1 (latest)

frigid anvil
#

I'm building a fairly standard web app with Remix, and have tons of places where I'd like to show small tips, notifications, onboarding tasks, warnings, etc. I'd like most of them to be dismiss-able by the user.

What strategy would you recommend to save a user's actions/preferences for something like this? My sense is that saving in a database is overkill, and that one all-encompassing 'UI Cookie' might be the best choice. I suppose the cookie could effectively be an object with a ui element id and then a boolean if the user has dismissed it. Then I'd read that data in my loaders and pass the flag values to the client.

Am I thinking about this the right way? Are there more elegant ways to achieve this or other things I'm missing? Thank you!

frail plume
#

I would store it in a DB, the cookie can be cleared and the user will lose their preferences

royal jewel
#

Agree with @frail plume use a db, it might seem like overkill but making users redo their preferences every time a cookie is cleared or they switch machines can be annoying and lead to users asking why you don’t store it somewhere persistent in the first place .

stark canyon
frigid anvil
#

Ok thanks everyone - very helpful, I'll store it in db.

This is a very beginner question, but would you just create a new column in a user_preferences table for every option (e.g. a dismissedOnboardingTip column), or create one column like ui_preferences and store all preferences in some json, or is there another approach? I think I'll have about 5-8 preferences to begin with, and that list will only grow.

soft hornet
#

I might just do one user_preferences table and store the userId, the preference (maybe as an enum), and the value.

#

Primary key would be (userId, preference)

#

You could also add a preferences table instead of an enum and store more metadata about each preference.

frail plume
#

I would do the same, a row per user per preference, so later you can add more without adding more columns

coral wolf
#

Whenever you have data that could grow infinitely over time, it should be modelled by new rows instead of new columns

soft hornet
#

I work for a sql database company and always happy to review schema.