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

OLD - frontend: PluginSettings: Rework plugin settings local storage usage #2596

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

vyncent-t
Copy link
Contributor

@vyncent-t vyncent-t commented Nov 21, 2024

Description

resolves issue #2595

This PR refactors the way Headlamp handles plugin settings stored in local storage, focusing on simplifying and improving the management of plugin states. Previously, the project stored the entire JSON data of plugin information in headlampPluginSettings, which included unnecessary details. This refactor reduces complexity by saving only the essential state information, improving performance and maintainability.

Key Changes

  1. Simplified Storage:

    • Replaced the old headlampPluginSettings structure with enabledPluginsList in local storage.
    • The new structure saves only the plugin name and its on/off state, eliminating the need to store complete JSON data.
  2. State Management Updates:

    • Introduced the pluginData slice in the plugin state to store plugin information.
    • Added enabledPlugins to maintain a list of plugins currently in use.
  3. Backward Compatibility:

    • The project now detects the existence of the old headlampPluginSettings in local storage.
    • If detected, it converts and migrates the old settings into the new enabledPluginsList format automatically upon visiting the plugin settings page.

Steps to Test

To verify the changes and ensure backward compatibility:

  1. Setup:

    • Start on the main branch with multiple plugins installed.
    • Disable one plugin while keeping others enabled, and save the settings.
    • Open the browser’s local storage and confirm that the disabled plugin’s state is saved in the headlampPluginSettings JSON.
  2. Switch to this Branch:

    • Checkout this branch and navigate to the plugin settings page.
  3. Observe Migration:

    • Confirm that the page detects the headlampPluginSettings in local storage, migrates the settings into a new enabledPluginsList object, deletes the old headlampPluginSettings, and reloads the page.
    • Verify that the plugin states from the previous settings are preserved in the new format.
  4. Post-Migration:

    • Ensure that plugin settings updates are correctly saved in the new enabledPluginsList structure.
    • Confirm that enabling/disabling plugins reflects accurately on subsequent reloads.

Notes

  • It improves the performance and clarity of plugin state management by reducing storage overhead.
  • The migration process ensures a seamless transition for users upgrading from previous versions.

@vyncent-t vyncent-t added the frontend Issues related to the frontend label Nov 21, 2024
@vyncent-t vyncent-t self-assigned this Nov 21, 2024
@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch 7 times, most recently from 825bbe1 to 5ba4e15 Compare November 25, 2024 18:10
@vyncent-t
Copy link
Contributor Author

last push

  • allows old storage settings to be migrated to the new settings

@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch from 5ba4e15 to 6b0ad82 Compare November 25, 2024 18:17
@vyncent-t
Copy link
Contributor Author

last push fixes merge conflicts

@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch from 6b0ad82 to fb4cd59 Compare November 27, 2024 17:30
@vyncent-t
Copy link
Contributor Author

last push rebases and fixes storybook

@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch 2 times, most recently from e257f80 to 0e02bf1 Compare November 27, 2024 18:21
@vyncent-t vyncent-t changed the title WIP: frontend: PluginSettings: Rework plugin settings local storage usage frontend: PluginSettings: Rework plugin settings local storage usage Nov 27, 2024
@vyncent-t vyncent-t marked this pull request as ready for review November 27, 2024 18:32
@dosubot dosubot bot added the size:XL This PR changes 500-999 lines, ignoring generated files. label Nov 27, 2024
Copy link
Collaborator

@joaquimrocha joaquimrocha left a comment

Choose a reason for hiding this comment

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

I am a bit surprised this needs so many changes. Wasn't the idea just to remove the saving of the whole package.json from the settings and use just the plugin name instead? Even if we change the name of the key in local storage, or move it to index db, why are we touching the plugin settings this much?

I would also like to understand: are plugins now supposed to be disabled by default? I understood that shipped plugins need to be enabled by default, and that the other ones were also like that for keeping a consistent behavior with the previous versions.

@vyncent-t vyncent-t marked this pull request as draft December 2, 2024 15:40
@vyncent-t
Copy link
Contributor Author

noticed some weird behavior when not using any of the old headlampPluginSettings or enabledPluginsList in local storage, working on a fix again

@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch from 0e02bf1 to 5c99964 Compare December 2, 2024 16:38
@vyncent-t vyncent-t marked this pull request as ready for review December 2, 2024 16:38
@dosubot dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. and removed size:XL This PR changes 500-999 lines, ignoring generated files. labels Dec 2, 2024
@vyncent-t
Copy link
Contributor Author

some meeting notes

  • can keep the enabledPluginsList to handle toggles
  • may need to handle default loading state of a plugin if they come disabled or enabled but most come enabled as of current
  • handled the backwards compatibility for users on pervious vers that allow migration of old settings to new settings

@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch from 5c99964 to 8ff265d Compare December 6, 2024 17:11
@vyncent-t
Copy link
Contributor Author

attempting to use the npm link to try to work on the slide plugin changes for updated state

@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch 3 times, most recently from 8044116 to a52a8d6 Compare December 6, 2024 17:41
Copy link
Contributor

@sniok sniok left a comment

Choose a reason for hiding this comment

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

Left some comments. Let me know if you need any help with testing using npm link

frontend/src/plugin/pluginsSlice.ts Outdated Show resolved Hide resolved
@@ -284,15 +278,69 @@ export function PluginSettingsPure(props: PluginSettingsPureProps) {
export default function PluginSettings() {
const dispatch = useDispatch();

const pluginSettings = useTypedSelector(state => state.plugins.pluginSettings);
const pluginData = useTypedSelector(state => state.plugins.pluginData);
Copy link
Contributor

Choose a reason for hiding this comment

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

all this logic should probably be moved to a useEffect

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have tried placing it in useEffect before but it would either error out entirely or cause extra re renders often so I had opted for controlled re renders using the page reload

@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch 2 times, most recently from 260ee6e to 70e720f Compare December 9, 2024 20:16
@vyncent-t vyncent-t force-pushed the plugin-settings-storage-refactor branch from 70e720f to 99ae0ec Compare December 10, 2024 16:00
Copy link
Collaborator

@joaquimrocha joaquimrocha left a comment

Choose a reason for hiding this comment

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

Left some comments. I think this PR looks too risky to me as it's doing many things when the original reasons why we were touching this part of the code was so we 1. didn't have the plugins version/data coming from a client-side stored version of it; 2. avoid having to store all that data when what we are interested in is checking whether the plugins are enabled on the user's side.

I suggest the following: turn this PR into draft so you keep any relevant changes for later.
And for now let's focus on:

  1. Not having the data for the plugin be populated from the client-side stored version (but instead use whatever comes from the backend)
  2. Keep just the plugin name + isEnabled stored in the headlampPluginSettings record for now. Don't rename it or change the format as I had suggested for now.

Later on we can optimize these changes based on pieces you have here, but I really want to fix the other issues in an isolated way first.

const [pluginChanges, setPluginChanges] = useState(() =>
pluginArr.map((plugin: PluginInfo) => {
const [pluginChanges, setPluginChanges] = useState<PluginInfo[]>(
props.plugins.map((plugin: PluginInfo) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of using props. everywhere you need to use the variables, just please declare them as the first line in the function:
const { plugins, ... } = props;
then it's better to use the variables without props.

Comment on lines +49 to +53
const enabledList = arr.reduce((acc, p) => {
acc[p.name] = !!p.isEnabled;
return acc;
}, {} as Record<string, boolean>);
return enabledList;
Copy link
Collaborator

Choose a reason for hiding this comment

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

This seems overly complex for its purpose. Also it says it creates a list but it creates a record.

dispatch(reloadPage());
} else {
/**
* NOTE: For compatibility with old settings, we need to check if the `localEnabledList` exists.
Copy link
Collaborator

Choose a reason for hiding this comment

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

So we have 2 deprecated items? headlampPluginSettings + enabledPluginsList?
I thought this was just about fixing the former, where we were storing the package.json contents for no reason, when what we were apparently using that list for was just to check if the plugins were enabled.

Comment on lines -292 to +331
onSave={plugins => {
dispatch(setPluginSettings(plugins));
dispatch(reloadPage());
}}
plugins={pluginData}
pluginsEnabledMap={pluginsEnabledMap}
onSave={() => {}}
Copy link
Collaborator

Choose a reason for hiding this comment

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

So on save we do nothing? I am confused with what this PR is supposed to fix now.

@joaquimrocha joaquimrocha marked this pull request as draft December 11, 2024 11:54
@vyncent-t vyncent-t changed the title frontend: PluginSettings: Rework plugin settings local storage usage OLD - frontend: PluginSettings: Rework plugin settings local storage usage Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
frontend Issues related to the frontend size:L This PR changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants