Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consolidate persisted settings state #1018

Open
achou11 opened this issue Mar 5, 2025 · 0 comments
Open

Consolidate persisted settings state #1018

achou11 opened this issue Mar 5, 2025 · 0 comments
Assignees

Comments

@achou11
Copy link
Member

achou11 commented Mar 5, 2025

Currently we have various settings-related values that we store as persisted state:

  • language
  • passcode
  • obscure code
  • metrics diagnostics permissions
  • coordinate format
  • manual coordinate entry format

under the hood, each of these are stored as separate entries in the local storage in the following ways:

  • language
  • passcode + obscure code
  • metrics diagnostics permissions
  • coordinate format + manual coordinate entry format

The proposed idea would be to have these all grouped in the same storage entry, which would make it easier to discover and manage persisted settings-related values. Access to these values can still be granular by implementing custom hooks that access the desired values using state selectors.

An idea for what the shape of the persisted state can look like:

type SettingsState = {
  locale: {
    languageTag: string | null
  },
  security: {
    passcode: string | null
    obscureCode: string | null
  },
  metrics: {
    diagnosticsPermissionsEnabled: boolean 
  },
  // Ideally these two are nested but can't think of a good name...
  coordinateFormat: CoordinateFormat;
  manualCoordinateEntryFormat: manualCoordinateEntryFormat;
}

The nesting of values might be overkill and I'm open to making things flatter.

Questions:

  • how much do we care about preserving backwards compatibility? the answer may depend on which value we're talking about e.g. not preserving the previous language code is not as detrimental compared to not preserving the diagnostics permissions. I think ideally we preserve and move existing values from the previous storage locations to this new one, but will probably mean some additional code to handle that gracefully.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant