-
Notifications
You must be signed in to change notification settings - Fork 182
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
base: main
Are you sure you want to change the base?
Conversation
825bbe1
to
5ba4e15
Compare
last push
|
5ba4e15
to
6b0ad82
Compare
last push fixes merge conflicts |
6b0ad82
to
fb4cd59
Compare
last push rebases and fixes storybook |
e257f80
to
0e02bf1
Compare
There was a problem hiding this 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.
noticed some weird behavior when not using any of the old |
0e02bf1
to
5c99964
Compare
some meeting notes
|
5c99964
to
8ff265d
Compare
attempting to use the npm link to try to work on the slide plugin changes for updated state |
8044116
to
a52a8d6
Compare
There was a problem hiding this 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
@@ -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); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
260ee6e
to
70e720f
Compare
Signed-off-by: Vincent T <[email protected]>
70e720f
to
99ae0ec
Compare
There was a problem hiding this 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:
- Not having the data for the plugin be populated from the client-side stored version (but instead use whatever comes from the backend)
- 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) => { |
There was a problem hiding this comment.
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.
const enabledList = arr.reduce((acc, p) => { | ||
acc[p.name] = !!p.isEnabled; | ||
return acc; | ||
}, {} as Record<string, boolean>); | ||
return enabledList; |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
onSave={plugins => { | ||
dispatch(setPluginSettings(plugins)); | ||
dispatch(reloadPage()); | ||
}} | ||
plugins={pluginData} | ||
pluginsEnabledMap={pluginsEnabledMap} | ||
onSave={() => {}} |
There was a problem hiding this comment.
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.
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
Simplified Storage:
headlampPluginSettings
structure withenabledPluginsList
in local storage.on/off
state, eliminating the need to store complete JSON data.State Management Updates:
pluginData
slice in the plugin state to store plugin information.enabledPlugins
to maintain a list of plugins currently in use.Backward Compatibility:
headlampPluginSettings
in local storage.enabledPluginsList
format automatically upon visiting the plugin settings page.Steps to Test
To verify the changes and ensure backward compatibility:
Setup:
main
branch with multiple plugins installed.headlampPluginSettings
JSON.Switch to this Branch:
Observe Migration:
headlampPluginSettings
in local storage, migrates the settings into a newenabledPluginsList
object, deletes the oldheadlampPluginSettings
, and reloads the page.Post-Migration:
enabledPluginsList
structure.Notes