Options modal resets saved settings when reopened/closed

[Titas-Ghosh]

Hi @pradeeban ,
I've identified a data persistence bug in the concore-editor where the Options modal unintentionally overwrites current settings with hardcoded defaults.
Currently, the modal initializes to empty values (e.g., false or "") instead of pulling from the superState. Since the modal dispatches SET_OPTIONS upon closing, simply opening and closing the window even without user input, wipes out existing configurations for Docker, Octave, and critical parameters like maxTime. This creates significant onboarding friction for anyone who need their environment settings to remain persistent.

The Options modal should be "state aware." On open, all fields should prefill with values currently stored in the superState, closing should only update values if the user has explicitly modified them. i think the main cause of this issue might be that the OptionsModal local state is not (synced) from the superState when the modal is triggered.

to fix this , i am thinking of implementing a synchronization step when superState.optionsModal is active, before user interaction, the local state should be populated with the current superState values to ensure configuration integrity.

[Titas-Ghosh]

I have opened the PR #351 implementing the fix that i stated , kindly review and check once you get chance @pradeeban

also on a curious note, while working on this, i noticed how the superState handles these global configurations. As we look toward the usability enhancements for GSoC, do you see us moving toward a more modular state management for the editor (like a dedicated context for environment specific configs), or should we continue expanding the current superState to keep the architecture centralized? i am thinking about the maintainability and the render performance in the long term.

[pradeeban]

@Titas-Ghosh Modular state managements surely make sense. The usability enhancements largely look from the user's perspective rather than the developer perspective, just to be clear.

[Titas-Ghosh]

Thanks for the clarification @pradeeban, that makes sense, i’ll prioritize usability changes from the end user workflow first, and treat modular state management as an implementation detail to support that, not as the goal itself