You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
typeSettingsState={locale: {languageTag: string|null},security: {passcode: string|nullobscureCode: 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.
The text was updated successfully, but these errors were encountered:
Currently we have various settings-related values that we store as persisted state:
under the hood, each of these are stored as separate entries in the local storage in the following ways:
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:
The nesting of values might be overkill and I'm open to making things flatter.
Questions:
The text was updated successfully, but these errors were encountered: