1

I'm developing a LWC and am including the ability for users to customize their view of the app. I'm wondering what are best practices regarding where to store the JSON that contains these preferences? No sensitive data, just view related stuff.

Text field on the User (or other) object?

Custom metadata?

I'm not worried about packaging this as a managed app.

2

Usually to store user preferences, it is best to use localStorage.

  1. It does not have expiration so will be valid unless and until you clear it programatically or user clears it in browser manually .
  2. Because it is not expired, if the localStorage gets corrupted for some reason (may be poor logic in code where you are storing Object instead of array), you should handle to clear it and notify user .
  3. It can store only strings - so you should use stringify and parse to store items in it .

Sample code:

@track userPreferences;

connectedCallback() {
    if (localStorage.getItem('userPreferences')) 
        this.userPreferences = JSON.parse(localStorage.getItem('userPreferences'));
    else 
        localStorage.setItem('userPreferences', JSON.stringify({}));
}

clearPreferences() {
    localStorage.setItem('userPreferences', JSON.stringify({}));
}

storeSomePreference() {
    this.userPreferences = {
        ...this.userPreferences,
        divPlacement: 'right'
        // some other preferences
    };
    localStorage.setItem('userPreferences', JSON.stringify(this.userPreferences));
} 
0

If you want the settings to be available to a user across all devices, use Custom Settings. In this case, you wouldn't store a JSON, as the field limits are pretty small, but instead just save/load/delete these records like normal records, except that they have a "Owner", which may be a global default (Org), per-profile, or per-user. Otherwise, you can put this data almost anywhere--it could be a custom text area on the user record, a hidden custom object (one with no tab, no parent object, and private sharing), or other options. I'd actually recommend avoiding Custom Metadata, because it is relatively hard to work with compared to Custom Settings and other "normal" types of records.

Not the answer you're looking for? Browse other questions tagged or ask your own question.