refactor(backend): phase 2 - split commands.rs by domain (100%)
Split monolithic commands.rs (1525 lines) into 7 domain-focused modules
to improve maintainability and readability while preserving the external API.
## Changes
### Module Structure
Created `commands/` directory with domain-based organization:
- **provider.rs** (946 lines, 15 commands)
- Provider CRUD operations (get, add, update, delete, switch)
- Usage query integration
- Endpoint speed testing and custom endpoint management
- Sort order management
- Largest file but highly cohesive (all provider-related)
- **mcp.rs** (235 lines, 13 commands)
- Claude MCP management (~/.claude.json)
- SSOT MCP config management (config.json)
- Sync operations (Claude ↔ Codex)
- Import/export functionality
- **config.rs** (153 lines, 8 commands)
- Config path queries (Claude/Codex)
- Directory operations (open, pick)
- Config status checks
- Parameter compatibility layer (app_type/app/appType)
- **settings.rs** (40 lines, 5 commands)
- App settings management
- App restart functionality
- app_config_dir override (Store integration)
- **plugin.rs** (36 lines, 4 commands)
- Claude plugin management (~/.claude/config.json)
- Plugin status and config operations
- **misc.rs** (45 lines, 3 commands)
- External link handling
- Update checks
- Portable mode detection
- **mod.rs** (15 lines)
- Module exports via `pub use`
- Preserves flat API structure
### API Preservation
- Used `pub use` pattern to maintain external API
- All commands still accessible as `commands::function_name`
- Zero breaking changes for frontend code
- lib.rs invoke_handler unchanged (48 commands registered)
## Statistics
- Files: 1 → 7 (modular organization)
- Lines: 1525 → 1470 (net -55 lines, -3.6%)
- Commands: 48 → 48 (all preserved)
- Average file size: 210 lines (excluding provider.rs)
- Compilation: ✅ Success (6.92s, 0 warnings)
- Tests: ✅ 4/4 passed
## Benefits
- **Maintainability**: Easier to locate and modify domain-specific code
- **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines
- **Testability**: Can unit test individual modules in isolation
- **Scalability**: Clear pattern for adding new command groups
- **Zero Risk**: No API changes, all tests passing
## Design Decisions
1. **Domain-based split**: Organized by business domain (provider, mcp, config)
rather than technical layers (crud, query, sync)
2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion
(all provider-related operations together). Can be further split in Phase 2.1
if needed.
3. **Parameter compatibility**: Retained multiple parameter names (app_type, app,
appType) for backward compatibility with different frontend call styles
## Phase 2 Status: ✅ 100% Complete
Ready for Phase 3: Adding integration tests.
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
|
|
|
#![allow(non_snake_case)]
|
|
|
|
|
|
|
|
|
|
use tauri::AppHandle;
|
|
|
|
|
use tauri_plugin_dialog::DialogExt;
|
|
|
|
|
use tauri_plugin_opener::OpenerExt;
|
|
|
|
|
|
|
|
|
|
use crate::app_config::AppType;
|
|
|
|
|
use crate::codex_config;
|
|
|
|
|
use crate::config::{self, get_claude_settings_path, ConfigStatus};
|
|
|
|
|
|
|
|
|
|
/// 获取 Claude Code 配置状态
|
|
|
|
|
#[tauri::command]
|
|
|
|
|
pub async fn get_claude_config_status() -> Result<ConfigStatus, String> {
|
|
|
|
|
Ok(config::get_claude_config_status())
|
|
|
|
|
}
|
|
|
|
|
|
2025-10-30 12:33:35 +08:00
|
|
|
use std::str::FromStr;
|
refactor(backend): phase 2 - split commands.rs by domain (100%)
Split monolithic commands.rs (1525 lines) into 7 domain-focused modules
to improve maintainability and readability while preserving the external API.
## Changes
### Module Structure
Created `commands/` directory with domain-based organization:
- **provider.rs** (946 lines, 15 commands)
- Provider CRUD operations (get, add, update, delete, switch)
- Usage query integration
- Endpoint speed testing and custom endpoint management
- Sort order management
- Largest file but highly cohesive (all provider-related)
- **mcp.rs** (235 lines, 13 commands)
- Claude MCP management (~/.claude.json)
- SSOT MCP config management (config.json)
- Sync operations (Claude ↔ Codex)
- Import/export functionality
- **config.rs** (153 lines, 8 commands)
- Config path queries (Claude/Codex)
- Directory operations (open, pick)
- Config status checks
- Parameter compatibility layer (app_type/app/appType)
- **settings.rs** (40 lines, 5 commands)
- App settings management
- App restart functionality
- app_config_dir override (Store integration)
- **plugin.rs** (36 lines, 4 commands)
- Claude plugin management (~/.claude/config.json)
- Plugin status and config operations
- **misc.rs** (45 lines, 3 commands)
- External link handling
- Update checks
- Portable mode detection
- **mod.rs** (15 lines)
- Module exports via `pub use`
- Preserves flat API structure
### API Preservation
- Used `pub use` pattern to maintain external API
- All commands still accessible as `commands::function_name`
- Zero breaking changes for frontend code
- lib.rs invoke_handler unchanged (48 commands registered)
## Statistics
- Files: 1 → 7 (modular organization)
- Lines: 1525 → 1470 (net -55 lines, -3.6%)
- Commands: 48 → 48 (all preserved)
- Average file size: 210 lines (excluding provider.rs)
- Compilation: ✅ Success (6.92s, 0 warnings)
- Tests: ✅ 4/4 passed
## Benefits
- **Maintainability**: Easier to locate and modify domain-specific code
- **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines
- **Testability**: Can unit test individual modules in isolation
- **Scalability**: Clear pattern for adding new command groups
- **Zero Risk**: No API changes, all tests passing
## Design Decisions
1. **Domain-based split**: Organized by business domain (provider, mcp, config)
rather than technical layers (crud, query, sync)
2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion
(all provider-related operations together). Can be further split in Phase 2.1
if needed.
3. **Parameter compatibility**: Retained multiple parameter names (app_type, app,
appType) for backward compatibility with different frontend call styles
## Phase 2 Status: ✅ 100% Complete
Ready for Phase 3: Adding integration tests.
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
|
|
|
|
2025-10-30 11:35:14 +08:00
|
|
|
#[tauri::command]
|
|
|
|
|
pub async fn get_config_status(app: String) -> Result<ConfigStatus, String> {
|
2025-10-30 12:33:35 +08:00
|
|
|
match AppType::from_str(&app).map_err(|e| e.to_string())? {
|
refactor(backend): phase 2 - split commands.rs by domain (100%)
Split monolithic commands.rs (1525 lines) into 7 domain-focused modules
to improve maintainability and readability while preserving the external API.
## Changes
### Module Structure
Created `commands/` directory with domain-based organization:
- **provider.rs** (946 lines, 15 commands)
- Provider CRUD operations (get, add, update, delete, switch)
- Usage query integration
- Endpoint speed testing and custom endpoint management
- Sort order management
- Largest file but highly cohesive (all provider-related)
- **mcp.rs** (235 lines, 13 commands)
- Claude MCP management (~/.claude.json)
- SSOT MCP config management (config.json)
- Sync operations (Claude ↔ Codex)
- Import/export functionality
- **config.rs** (153 lines, 8 commands)
- Config path queries (Claude/Codex)
- Directory operations (open, pick)
- Config status checks
- Parameter compatibility layer (app_type/app/appType)
- **settings.rs** (40 lines, 5 commands)
- App settings management
- App restart functionality
- app_config_dir override (Store integration)
- **plugin.rs** (36 lines, 4 commands)
- Claude plugin management (~/.claude/config.json)
- Plugin status and config operations
- **misc.rs** (45 lines, 3 commands)
- External link handling
- Update checks
- Portable mode detection
- **mod.rs** (15 lines)
- Module exports via `pub use`
- Preserves flat API structure
### API Preservation
- Used `pub use` pattern to maintain external API
- All commands still accessible as `commands::function_name`
- Zero breaking changes for frontend code
- lib.rs invoke_handler unchanged (48 commands registered)
## Statistics
- Files: 1 → 7 (modular organization)
- Lines: 1525 → 1470 (net -55 lines, -3.6%)
- Commands: 48 → 48 (all preserved)
- Average file size: 210 lines (excluding provider.rs)
- Compilation: ✅ Success (6.92s, 0 warnings)
- Tests: ✅ 4/4 passed
## Benefits
- **Maintainability**: Easier to locate and modify domain-specific code
- **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines
- **Testability**: Can unit test individual modules in isolation
- **Scalability**: Clear pattern for adding new command groups
- **Zero Risk**: No API changes, all tests passing
## Design Decisions
1. **Domain-based split**: Organized by business domain (provider, mcp, config)
rather than technical layers (crud, query, sync)
2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion
(all provider-related operations together). Can be further split in Phase 2.1
if needed.
3. **Parameter compatibility**: Retained multiple parameter names (app_type, app,
appType) for backward compatibility with different frontend call styles
## Phase 2 Status: ✅ 100% Complete
Ready for Phase 3: Adding integration tests.
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
|
|
|
AppType::Claude => Ok(config::get_claude_config_status()),
|
|
|
|
|
AppType::Codex => {
|
|
|
|
|
let auth_path = codex_config::get_codex_auth_path();
|
|
|
|
|
let exists = auth_path.exists();
|
|
|
|
|
let path = codex_config::get_codex_config_dir()
|
|
|
|
|
.to_string_lossy()
|
|
|
|
|
.to_string();
|
|
|
|
|
|
|
|
|
|
Ok(ConfigStatus { exists, path })
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// 获取 Claude Code 配置文件路径
|
|
|
|
|
#[tauri::command]
|
|
|
|
|
pub async fn get_claude_code_config_path() -> Result<String, String> {
|
|
|
|
|
Ok(get_claude_settings_path().to_string_lossy().to_string())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// 获取当前生效的配置目录
|
|
|
|
|
#[tauri::command]
|
2025-10-30 11:35:14 +08:00
|
|
|
pub async fn get_config_dir(app: String) -> Result<String, String> {
|
2025-10-30 12:33:35 +08:00
|
|
|
let dir = match AppType::from_str(&app).map_err(|e| e.to_string())? {
|
refactor(backend): phase 2 - split commands.rs by domain (100%)
Split monolithic commands.rs (1525 lines) into 7 domain-focused modules
to improve maintainability and readability while preserving the external API.
## Changes
### Module Structure
Created `commands/` directory with domain-based organization:
- **provider.rs** (946 lines, 15 commands)
- Provider CRUD operations (get, add, update, delete, switch)
- Usage query integration
- Endpoint speed testing and custom endpoint management
- Sort order management
- Largest file but highly cohesive (all provider-related)
- **mcp.rs** (235 lines, 13 commands)
- Claude MCP management (~/.claude.json)
- SSOT MCP config management (config.json)
- Sync operations (Claude ↔ Codex)
- Import/export functionality
- **config.rs** (153 lines, 8 commands)
- Config path queries (Claude/Codex)
- Directory operations (open, pick)
- Config status checks
- Parameter compatibility layer (app_type/app/appType)
- **settings.rs** (40 lines, 5 commands)
- App settings management
- App restart functionality
- app_config_dir override (Store integration)
- **plugin.rs** (36 lines, 4 commands)
- Claude plugin management (~/.claude/config.json)
- Plugin status and config operations
- **misc.rs** (45 lines, 3 commands)
- External link handling
- Update checks
- Portable mode detection
- **mod.rs** (15 lines)
- Module exports via `pub use`
- Preserves flat API structure
### API Preservation
- Used `pub use` pattern to maintain external API
- All commands still accessible as `commands::function_name`
- Zero breaking changes for frontend code
- lib.rs invoke_handler unchanged (48 commands registered)
## Statistics
- Files: 1 → 7 (modular organization)
- Lines: 1525 → 1470 (net -55 lines, -3.6%)
- Commands: 48 → 48 (all preserved)
- Average file size: 210 lines (excluding provider.rs)
- Compilation: ✅ Success (6.92s, 0 warnings)
- Tests: ✅ 4/4 passed
## Benefits
- **Maintainability**: Easier to locate and modify domain-specific code
- **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines
- **Testability**: Can unit test individual modules in isolation
- **Scalability**: Clear pattern for adding new command groups
- **Zero Risk**: No API changes, all tests passing
## Design Decisions
1. **Domain-based split**: Organized by business domain (provider, mcp, config)
rather than technical layers (crud, query, sync)
2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion
(all provider-related operations together). Can be further split in Phase 2.1
if needed.
3. **Parameter compatibility**: Retained multiple parameter names (app_type, app,
appType) for backward compatibility with different frontend call styles
## Phase 2 Status: ✅ 100% Complete
Ready for Phase 3: Adding integration tests.
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
|
|
|
AppType::Claude => config::get_claude_config_dir(),
|
|
|
|
|
AppType::Codex => codex_config::get_codex_config_dir(),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
Ok(dir.to_string_lossy().to_string())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// 打开配置文件夹
|
|
|
|
|
#[tauri::command]
|
2025-10-30 11:35:14 +08:00
|
|
|
pub async fn open_config_folder(handle: AppHandle, app: String) -> Result<bool, String> {
|
2025-10-30 12:33:35 +08:00
|
|
|
let config_dir = match AppType::from_str(&app).map_err(|e| e.to_string())? {
|
refactor(backend): phase 2 - split commands.rs by domain (100%)
Split monolithic commands.rs (1525 lines) into 7 domain-focused modules
to improve maintainability and readability while preserving the external API.
## Changes
### Module Structure
Created `commands/` directory with domain-based organization:
- **provider.rs** (946 lines, 15 commands)
- Provider CRUD operations (get, add, update, delete, switch)
- Usage query integration
- Endpoint speed testing and custom endpoint management
- Sort order management
- Largest file but highly cohesive (all provider-related)
- **mcp.rs** (235 lines, 13 commands)
- Claude MCP management (~/.claude.json)
- SSOT MCP config management (config.json)
- Sync operations (Claude ↔ Codex)
- Import/export functionality
- **config.rs** (153 lines, 8 commands)
- Config path queries (Claude/Codex)
- Directory operations (open, pick)
- Config status checks
- Parameter compatibility layer (app_type/app/appType)
- **settings.rs** (40 lines, 5 commands)
- App settings management
- App restart functionality
- app_config_dir override (Store integration)
- **plugin.rs** (36 lines, 4 commands)
- Claude plugin management (~/.claude/config.json)
- Plugin status and config operations
- **misc.rs** (45 lines, 3 commands)
- External link handling
- Update checks
- Portable mode detection
- **mod.rs** (15 lines)
- Module exports via `pub use`
- Preserves flat API structure
### API Preservation
- Used `pub use` pattern to maintain external API
- All commands still accessible as `commands::function_name`
- Zero breaking changes for frontend code
- lib.rs invoke_handler unchanged (48 commands registered)
## Statistics
- Files: 1 → 7 (modular organization)
- Lines: 1525 → 1470 (net -55 lines, -3.6%)
- Commands: 48 → 48 (all preserved)
- Average file size: 210 lines (excluding provider.rs)
- Compilation: ✅ Success (6.92s, 0 warnings)
- Tests: ✅ 4/4 passed
## Benefits
- **Maintainability**: Easier to locate and modify domain-specific code
- **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines
- **Testability**: Can unit test individual modules in isolation
- **Scalability**: Clear pattern for adding new command groups
- **Zero Risk**: No API changes, all tests passing
## Design Decisions
1. **Domain-based split**: Organized by business domain (provider, mcp, config)
rather than technical layers (crud, query, sync)
2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion
(all provider-related operations together). Can be further split in Phase 2.1
if needed.
3. **Parameter compatibility**: Retained multiple parameter names (app_type, app,
appType) for backward compatibility with different frontend call styles
## Phase 2 Status: ✅ 100% Complete
Ready for Phase 3: Adding integration tests.
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
|
|
|
AppType::Claude => config::get_claude_config_dir(),
|
|
|
|
|
AppType::Codex => codex_config::get_codex_config_dir(),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
if !config_dir.exists() {
|
|
|
|
|
std::fs::create_dir_all(&config_dir).map_err(|e| format!("创建目录失败: {}", e))?;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
handle
|
|
|
|
|
.opener()
|
|
|
|
|
.open_path(config_dir.to_string_lossy().to_string(), None::<String>)
|
|
|
|
|
.map_err(|e| format!("打开文件夹失败: {}", e))?;
|
|
|
|
|
|
|
|
|
|
Ok(true)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// 弹出系统目录选择器并返回用户选择的路径
|
|
|
|
|
#[tauri::command]
|
|
|
|
|
pub async fn pick_directory(
|
|
|
|
|
app: AppHandle,
|
2025-11-05 23:17:34 +08:00
|
|
|
#[allow(non_snake_case)] defaultPath: Option<String>,
|
refactor(backend): phase 2 - split commands.rs by domain (100%)
Split monolithic commands.rs (1525 lines) into 7 domain-focused modules
to improve maintainability and readability while preserving the external API.
## Changes
### Module Structure
Created `commands/` directory with domain-based organization:
- **provider.rs** (946 lines, 15 commands)
- Provider CRUD operations (get, add, update, delete, switch)
- Usage query integration
- Endpoint speed testing and custom endpoint management
- Sort order management
- Largest file but highly cohesive (all provider-related)
- **mcp.rs** (235 lines, 13 commands)
- Claude MCP management (~/.claude.json)
- SSOT MCP config management (config.json)
- Sync operations (Claude ↔ Codex)
- Import/export functionality
- **config.rs** (153 lines, 8 commands)
- Config path queries (Claude/Codex)
- Directory operations (open, pick)
- Config status checks
- Parameter compatibility layer (app_type/app/appType)
- **settings.rs** (40 lines, 5 commands)
- App settings management
- App restart functionality
- app_config_dir override (Store integration)
- **plugin.rs** (36 lines, 4 commands)
- Claude plugin management (~/.claude/config.json)
- Plugin status and config operations
- **misc.rs** (45 lines, 3 commands)
- External link handling
- Update checks
- Portable mode detection
- **mod.rs** (15 lines)
- Module exports via `pub use`
- Preserves flat API structure
### API Preservation
- Used `pub use` pattern to maintain external API
- All commands still accessible as `commands::function_name`
- Zero breaking changes for frontend code
- lib.rs invoke_handler unchanged (48 commands registered)
## Statistics
- Files: 1 → 7 (modular organization)
- Lines: 1525 → 1470 (net -55 lines, -3.6%)
- Commands: 48 → 48 (all preserved)
- Average file size: 210 lines (excluding provider.rs)
- Compilation: ✅ Success (6.92s, 0 warnings)
- Tests: ✅ 4/4 passed
## Benefits
- **Maintainability**: Easier to locate and modify domain-specific code
- **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines
- **Testability**: Can unit test individual modules in isolation
- **Scalability**: Clear pattern for adding new command groups
- **Zero Risk**: No API changes, all tests passing
## Design Decisions
1. **Domain-based split**: Organized by business domain (provider, mcp, config)
rather than technical layers (crud, query, sync)
2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion
(all provider-related operations together). Can be further split in Phase 2.1
if needed.
3. **Parameter compatibility**: Retained multiple parameter names (app_type, app,
appType) for backward compatibility with different frontend call styles
## Phase 2 Status: ✅ 100% Complete
Ready for Phase 3: Adding integration tests.
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
|
|
|
) -> Result<Option<String>, String> {
|
refactor: migrate all Tauri commands to camelCase parameters
This commit addresses parameter naming inconsistencies caused by Tauri v2's
requirement for camelCase parameter names in IPC commands.
Backend changes (Rust):
- Updated all command parameters from snake_case to camelCase
- Commands affected:
* provider.rs: providerId (×4), timeoutSecs
* import_export.rs: filePath (×2), defaultName
* config.rs: defaultPath
- Added #[allow(non_snake_case)] attributes for camelCase parameters
- Removed unused QueryUsageParams struct
Frontend changes (TypeScript):
- Removed redundant snake_case parameters from all invoke() calls
- Updated API files:
* usage.ts: removed debug logs, unified to providerId
* vscode.ts: updated 8 functions (providerId, timeoutSecs, filePath, defaultName)
* settings.ts: updated 4 functions (defaultPath, filePath, defaultName)
- Ensured all parameters now use camelCase exclusively
Test updates:
- Updated MSW handlers to accept both old and new parameter formats during transition
- Added i18n mock compatibility for tests
Root cause:
The issue stemmed from Tauri v2 strictly requiring camelCase for command
parameters, while the codebase was using snake_case. This caused parameters
like 'provider_id' to not be recognized by the backend, resulting in
"missing providerId parameter" errors.
BREAKING CHANGE: All Tauri command invocations now require camelCase parameters.
Any external tools or scripts calling these commands must be updated accordingly.
Fixes: Usage query always failing with "missing providerId" error
Fixes: Custom endpoint management not receiving provider ID
Fixes: Import/export dialogs not respecting default paths
2025-11-03 16:50:23 +08:00
|
|
|
let initial = defaultPath
|
refactor(backend): phase 2 - split commands.rs by domain (100%)
Split monolithic commands.rs (1525 lines) into 7 domain-focused modules
to improve maintainability and readability while preserving the external API.
## Changes
### Module Structure
Created `commands/` directory with domain-based organization:
- **provider.rs** (946 lines, 15 commands)
- Provider CRUD operations (get, add, update, delete, switch)
- Usage query integration
- Endpoint speed testing and custom endpoint management
- Sort order management
- Largest file but highly cohesive (all provider-related)
- **mcp.rs** (235 lines, 13 commands)
- Claude MCP management (~/.claude.json)
- SSOT MCP config management (config.json)
- Sync operations (Claude ↔ Codex)
- Import/export functionality
- **config.rs** (153 lines, 8 commands)
- Config path queries (Claude/Codex)
- Directory operations (open, pick)
- Config status checks
- Parameter compatibility layer (app_type/app/appType)
- **settings.rs** (40 lines, 5 commands)
- App settings management
- App restart functionality
- app_config_dir override (Store integration)
- **plugin.rs** (36 lines, 4 commands)
- Claude plugin management (~/.claude/config.json)
- Plugin status and config operations
- **misc.rs** (45 lines, 3 commands)
- External link handling
- Update checks
- Portable mode detection
- **mod.rs** (15 lines)
- Module exports via `pub use`
- Preserves flat API structure
### API Preservation
- Used `pub use` pattern to maintain external API
- All commands still accessible as `commands::function_name`
- Zero breaking changes for frontend code
- lib.rs invoke_handler unchanged (48 commands registered)
## Statistics
- Files: 1 → 7 (modular organization)
- Lines: 1525 → 1470 (net -55 lines, -3.6%)
- Commands: 48 → 48 (all preserved)
- Average file size: 210 lines (excluding provider.rs)
- Compilation: ✅ Success (6.92s, 0 warnings)
- Tests: ✅ 4/4 passed
## Benefits
- **Maintainability**: Easier to locate and modify domain-specific code
- **Readability**: Smaller files (~200 lines) vs monolithic 1500+ lines
- **Testability**: Can unit test individual modules in isolation
- **Scalability**: Clear pattern for adding new command groups
- **Zero Risk**: No API changes, all tests passing
## Design Decisions
1. **Domain-based split**: Organized by business domain (provider, mcp, config)
rather than technical layers (crud, query, sync)
2. **Preserved provider.rs size**: Kept at 946 lines to maintain high cohesion
(all provider-related operations together). Can be further split in Phase 2.1
if needed.
3. **Parameter compatibility**: Retained multiple parameter names (app_type, app,
appType) for backward compatibility with different frontend call styles
## Phase 2 Status: ✅ 100% Complete
Ready for Phase 3: Adding integration tests.
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-27 22:18:05 +08:00
|
|
|
.map(|p| p.trim().to_string())
|
|
|
|
|
.filter(|p| !p.is_empty());
|
|
|
|
|
|
|
|
|
|
let result = tauri::async_runtime::spawn_blocking(move || {
|
|
|
|
|
let mut builder = app.dialog().file();
|
|
|
|
|
if let Some(path) = initial {
|
|
|
|
|
builder = builder.set_directory(path);
|
|
|
|
|
}
|
|
|
|
|
builder.blocking_pick_folder()
|
|
|
|
|
})
|
|
|
|
|
.await
|
|
|
|
|
.map_err(|e| format!("弹出目录选择器失败: {}", e))?;
|
|
|
|
|
|
|
|
|
|
match result {
|
|
|
|
|
Some(file_path) => {
|
|
|
|
|
let resolved = file_path
|
|
|
|
|
.simplified()
|
|
|
|
|
.into_path()
|
|
|
|
|
.map_err(|e| format!("解析选择的目录失败: {}", e))?;
|
|
|
|
|
Ok(Some(resolved.to_string_lossy().to_string()))
|
|
|
|
|
}
|
|
|
|
|
None => Ok(None),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// 获取应用配置文件路径
|
|
|
|
|
#[tauri::command]
|
|
|
|
|
pub async fn get_app_config_path() -> Result<String, String> {
|
|
|
|
|
let config_path = config::get_app_config_path();
|
|
|
|
|
Ok(config_path.to_string_lossy().to_string())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// 打开应用配置文件夹
|
|
|
|
|
#[tauri::command]
|
|
|
|
|
pub async fn open_app_config_folder(handle: AppHandle) -> Result<bool, String> {
|
|
|
|
|
let config_dir = config::get_app_config_dir();
|
|
|
|
|
|
|
|
|
|
if !config_dir.exists() {
|
|
|
|
|
std::fs::create_dir_all(&config_dir).map_err(|e| format!("创建目录失败: {}", e))?;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
handle
|
|
|
|
|
.opener()
|
|
|
|
|
.open_path(config_dir.to_string_lossy().to_string(), None::<String>)
|
|
|
|
|
.map_err(|e| format!("打开文件夹失败: {}", e))?;
|
|
|
|
|
|
|
|
|
|
Ok(true)
|
|
|
|
|
}
|