use generated kwargs and config in more hardcoded places

1 files changed, 145 insertions, 0 deletions

diff --git a/GENERATED_CODE_ANALYSIS.md b/GENERATED_CODE_ANALYSIS.md
new file mode 100644
index 0000000..86c37e6
--- /dev/null
+++ b/GENERATED_CODE_ANALYSIS.md
@@ -0,0 +1,145 @@
+# Generated Code Analysis and Improvement Opportunities
+
+## Generated Files Added to .gitignore ✅
+
+The following auto-generated files are now properly ignored:
+- `py_modules/lsfg_vk/config_schema_generated.py`
+- `py_modules/lsfg_vk/configuration_helpers_generated.py`
+- `src/config/generatedConfigSchema.ts`
+
+## Build Scripts Overview
+
+### 1. `scripts/generate_python_boilerplate.py`
+**Generates:**
+- `py_modules/lsfg_vk/config_schema_generated.py` - TypedDict, parsing logic, generation logic
+- `py_modules/lsfg_vk/configuration_helpers_generated.py` - Helper functions for logging, field access
+
+### 2. `scripts/generate_ts_schema.py`
+**Generates:**
+- `src/config/generatedConfigSchema.ts` - TypeScript interfaces, schema constants, defaults
+
+## Current Hardcoded Areas That Could Use Generated Code
+
+### Python Side Opportunities
+
+#### 1. **CRITICAL - Function Signatures** 🚨
+**File:** `py_modules/lsfg_vk/configuration.py:107-113`
+```python
+def update_config(self, dll: str, multiplier: int, flow_scale: float, 
+                 performance_mode: bool, hdr_mode: bool, 
+                 experimental_present_mode: str = "fifo", 
+                 dxvk_frame_rate: int = 0,
+                 enable_wow64: bool = False,
+                 disable_steamdeck_mode: bool = False,
+                 mangohud_workaround: bool = False,
+                 disable_vkbasalt: bool = False) -> ConfigurationResponse:
+```
+
+**Improvement:** The generated code already creates `get_function_parameters()` that returns the exact signature string. This method signature should be replaced with a generated version or simplified to use `**kwargs` with schema validation.
+
+#### 2. **Field Name String Literals** ⚠️
+**Multiple locations** - Field names used as string literals:
+- `config["dll"]` (multiple files)
+- `config["multiplier"]` etc.
+
+**Improvement:** Use the generated field constants or create typed access methods.
+
+#### 3. **Configuration Defaults** ⚠️
+**File:** Various locations where defaults are hardcoded
+**Improvement:** Always use `ConfigurationManager.get_defaults()` or generated default functions.
+
+#### 4. **Logging Format Strings** ✅ (Partially Done)
+**Status:** The `log_configuration_update()` function is already generated and used in some places, but could be used more consistently.
+
+### TypeScript Side Opportunities
+
+#### 1. **CRITICAL - Hardcoded Field Names in UI** 🚨
+**File:** `src/components/ConfigurationSection.tsx:48,60,69,78,104,146,164,173,182`
+
+```tsx
+onChange={(value) => onConfigChange('multiplier', value)}
+onChange={(value) => onConfigChange('flow_scale', value)}
+onChange={(value) => onConfigChange('performance_mode', value)}
+// ... etc for all 11 fields
+```
+
+**Improvement:** These string literals should use schema constants:
+```tsx
+import { getFieldNames } from '../config/generatedConfigSchema';
+// or use constants like
+onChange={(value) => onConfigChange('multiplier', value)} // fieldNames.multiplier
+```
+
+#### 2. **UI Component Generation** 🚀
+**Opportunity:** The entire `ConfigurationSection.tsx` could be generated from the schema definition since each field has:
+- `fieldType` (determines UI component type)
+- `description` (for labels/descriptions)  
+- `default` (for initial values)
+- `name` (for display names)
+
+#### 3. **Manual Type Definitions** ✅ (Already Done)
+**Status:** TypeScript types are already generated properly via `ConfigurationData` interface.
+
+#### 4. **Field Validation** 🚀
+**Opportunity:** Client-side validation could be generated from the schema field types and constraints.
+
+## High-Impact Improvements Recommended
+
+### Phase 1 - Critical Fixes (High Impact, Low Effort)
+
+1. **Replace hardcoded field name strings** with schema constants
+2. **Use generated default functions** everywhere instead of hardcoded defaults  
+3. **Consistent use of generated logging functions**
+
+### Phase 2 - Major Refactoring (High Impact, Medium Effort)
+
+1. **Replace `update_config()` parameter list** with generated signature or schema-based validation
+2. **Generate UI components** from schema instead of manual creation
+3. **Create typed field accessor methods** to eliminate string-based field access
+
+### Phase 3 - Advanced Features (Medium Impact, High Effort)
+
+1. **Generate client-side validation** from schema constraints
+2. **Auto-generate test cases** from schema definition
+3. **Generate documentation** from schema descriptions
+
+## Specific Next Steps
+
+### Immediate (Phase 1)
+1. Create field name constants in TypeScript and use them in ConfigurationSection
+2. Replace remaining hardcoded defaults with generated functions
+3. Add schema validation to Python configuration updates
+
+### Short Term (Phase 2)  
+1. Refactor Python `update_config()` method to use schema-driven approach
+2. Generate UI field components from schema metadata
+3. Create typed field accessor pattern
+
+### Long Term (Phase 3)
+1. Build complete schema-driven UI generation system
+2. Add schema versioning and migration support
+3. Generate comprehensive test suites from schema
+
+## Files That Should Be Modified
+
+### Python Files
+- `py_modules/lsfg_vk/configuration.py` - Method signatures, field access
+- `py_modules/lsfg_vk/plugin.py` - Field access patterns
+- `py_modules/lsfg_vk/config_schema.py` - Ensure all access uses generated code
+
+### TypeScript Files  
+- `src/components/ConfigurationSection.tsx` - Replace hardcoded field names
+- `src/config/configSchema.ts` - Add field name constants export
+- `src/api/lsfgApi.ts` - Ensure type safety with generated types
+
+### Build Process
+- Consider adding the generation scripts to VS Code tasks or package.json scripts
+- Add validation that generated files are up to date in CI/CD
+
+## Benefits of These Improvements
+
+1. **Single Source of Truth** - All configuration changes happen in `shared_config.py`
+2. **Type Safety** - Reduce runtime errors from typos in field names
+3. **Maintainability** - Adding new config fields requires minimal manual code changes
+4. **Consistency** - Generated code ensures consistent patterns across Python/TypeScript
+5. **Documentation** - Schema serves as living documentation of configuration options