refactor: flatten image generation settings structure

[daniel-lxs]

Summary

This PR refactors the image generation settings to use a flattened structure instead of nested objects, simplifying the codebase and improving maintainability.

Changes

Core Changes

• Moved openRouterImageApiKey and imageGenerationSelectedModel from nested imageGenerationSettings object to top-level properties
• Removed the imageGenerationSettings nested object entirely
• Added GLOBAL_SECRET_KEYS array to handle global secrets properly
• Updated SecretState type to include global secret keys

ContextProxy Simplification

• Removed complex nested secret handling logic (NESTED_SECRET_PATHS, hasNestedSecrets, etc.)
• Simplified getValue, setValue, and getValues methods
• Removed extractAndStoreNestedSecrets and mergeNestedSecrets helper functions

Component Updates

• Updated ImageGenerationSettings component to accept flattened props
• Updated ExperimentalSettings to pass flattened props
• Updated SettingsView to handle flattened state structure
• Fixed all related tests to work with the new structure

Type Fixes

• Added SecretState to RooCodeSettings type definition to properly handle global secrets
• Updated ExtensionState type to include openRouterImageApiKey as an optional property

Benefits

• Eliminates complex nested secret extraction/merging logic
• Improves code readability and maintainability
• Reduces potential for runtime errors from object mutations
• Simplifies state management in UI components

Testing

• All existing tests have been updated and pass
• TypeScript compilation succeeds
• Linting passes with no warnings

---

Important

Refactor image generation settings to a flattened structure, simplifying code and improving maintainability across components and types.

• Behavior:
  • Flattened image generation settings by moving openRouterImageApiKey and imageGenerationSelectedModel to top-level properties in global-settings.ts.
  • Removed imageGenerationSettings nested object.
  • Added GLOBAL_SECRET_KEYS for global secrets.
  • Updated SecretState type to include global secret keys.
• ContextProxy Simplification:
  • Removed nested secret handling logic in ContextProxy.ts.
  • Simplified getValue, setValue, and getValues methods.
  • Removed extractAndStoreNestedSecrets and mergeNestedSecrets functions.
• Component Updates:
  • Updated ImageGenerationSettings and ExperimentalSettings components to use flattened props.
  • Updated SettingsView to handle flattened state structure.
  • Adjusted related tests in ImageGenerationSettings.spec.tsx.
• Type Fixes:
  • Updated ExtensionState type in ExtensionMessage.ts to include openRouterImageApiKey and openRouterImageGenerationSelectedModel.
• Misc:
  • Updated webviewMessageHandler.ts to handle new message types for image generation settings.

^{This description was created by for bcc0c25. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Thank you for your contribution! I've reviewed the changes and found several issues that need attention before this can be merged. The refactoring to flatten the image generation settings structure is a good improvement, but there are some critical issues to address.

[roomote]

Is this intentional? Adding SecretState directly to RooCodeSettings creates a type intersection that might cause confusion. The SecretState type now includes both provider secrets and global secrets. Consider documenting this change or using a more explicit type composition:

Suggested change

	export type RooCodeSettings = GlobalSettings & ProviderSettings & SecretState
	export type RooCodeSettings = GlobalSettings & ProviderSettings & { openRouterImageApiKey?: string }

[roomote]

Could we add JSDoc comments here to explain the distinction between GLOBAL_SECRET_KEYS and SECRET_STATE_KEYS? This would help future maintainers understand why we need two separate arrays for secrets.

[roomote]

The cast to any here breaks type safety. Could we update the type definitions to properly include openRouterImageApiKey in the state values type? This suggests the types aren't properly aligned with the actual data structure.

[roomote]

For consistency with other model ID fields in the codebase, should this be named imageGenerationModelId instead of imageGenerationSelectedModel?

[roomote]

Additional Review Notes

I noticed a couple of additional issues that need attention:

1. Merge Conflicts

The PR currently has merge conflicts that need to be resolved before it can be merged. Please rebase or merge the latest changes from the main branch.

2. Migration Logic

Since this PR removes the nested openRouterImageGenerationSettings structure, existing users who have data stored in the old format will lose their settings. Consider adding migration logic to:

• Check for existing nested settings on first load
• Move the values to the new flattened structure
• Clean up the old nested structure

This could be done in the ContextProxy initialization or in a dedicated migration utility.

3. Test Coverage

While the tests have been updated to work with the new structure, consider adding specific test cases for:

• Migration from old nested structure to new flattened structure
• Secret storage and retrieval for the new global secrets
• Proper type checking for the flattened fields

Overall, this is a good refactoring that simplifies the codebase! Once these issues are addressed, it should be ready to merge.

[mrubens]

Should this be openRouterImageGenerationSelectedModel?

[daniel-lxs]

Should we leave this generic in case we want to add other models from other providers?

[mrubens]

Yeah I'm just not sure the right structure to support multiple providers. If we don't care about preserving the key when you switch between them, we might want imageApiProvider, imageApiKey, imageApiModelId?