Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

Cleanup tasks in the Settings code #12125

Merged
merged 5 commits into from
Jan 11, 2024
Merged

Cleanup tasks in the Settings code #12125

merged 5 commits into from
Jan 11, 2024

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Jan 9, 2024

A few cleanups; suggest reviewing commit-by-commit.

The changes are, approximately:

  • Combine SettingsStore.isEnabled and SettingsStore.canSetValue. Having two methods which do nearly-but-not-quite the same thing is confusing, and there's no good reason to have both.
  • Add an explicit Settings.configDisablesSetting to replace the magic where this works for a magic subset of settings.
  • Replace LEVELS_FEATURE with the identical but more descriptive LEVELS_DEVICE_ONLY_SETTINGS_WITH_CONFIG.

This change is marked as an internal change (Task), so will not be included in the changelog.

This was basically the same as `SettingsStore.canSetValue` only more confusing,
so let's get rid of it.
The current magic where this only works for features (but not beta features!)
is, well, magical. And I need more flexibility here.
I don't know if this was ever intended to have different semantics to
`LEVELS_DEVICE_ONLY_SETTINGS_WITH_CONFIG`, but if it was, those semantics
shuold have been written down. They now seem to be used entirely
interchangably.

const label = this.props.label ?? SettingsStore.getDisplayName(this.props.name, this.props.level);
const description = SettingsStore.getDescription(this.props.name);
const shouldWarn = SettingsStore.shouldHaveWarning(this.props.name);
const disabled = this.state.disabled || !canChange;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note that it was impossible for canChange to be true while state.disabled was true, so this was equivalent to const disabled = !canChange;.

@richvdh richvdh added this pull request to the merge queue Jan 11, 2024
Copy link
Contributor

@florianduros florianduros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A question :)

@@ -62,7 +62,7 @@ export default class CryptographyPanel extends React.Component<IProps, IState> {
}

let noSendUnverifiedSetting: JSX.Element | undefined;
if (SettingsStore.isEnabled("blacklistUnverifiedDevices")) {
if (SettingsStore.canSetValue("blacklistUnverifiedDevices", null, SettingLevel.DEVICE)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is at true if we can set the blacklistUnverifiedDevices settings on this device ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Which makes sense, because that's what's going to happen when you toggle the SettingsFlag.

Merged via the queue into develop with commit 65d6bfe Jan 11, 2024
24 checks passed
@richvdh richvdh deleted the rav/settings_cleanup branch January 11, 2024 10:13
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T-Task Refactoring, enabling or disabling functionality, other engineering tasks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants