mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-02-27 18:22:41 -08:00
update tasks
This commit is contained in:
@@ -0,0 +1,53 @@
|
||||
---
|
||||
id: TASK-10
|
||||
title: Consolidate service naming conventions and barrel exports
|
||||
status: Done
|
||||
assignee: []
|
||||
created_date: '2026-02-11 08:21'
|
||||
updated_date: '2026-02-15 07:00'
|
||||
labels:
|
||||
- refactor
|
||||
- services
|
||||
- naming
|
||||
milestone: Codebase Clarity & Composability
|
||||
dependencies: []
|
||||
references:
|
||||
- src/core/services/index.ts
|
||||
priority: low
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
The service layer has inconsistent naming:
|
||||
- Some functions end in `Service`: `handleCliCommandService`, `loadSubtitlePositionService`
|
||||
- Some end in `RuntimeService`: `replayCurrentSubtitleRuntimeService`, `sendMpvCommandRuntimeService`
|
||||
- Some are plain: `shortcutMatchesInputForLocalFallback`
|
||||
- Factory functions mix `create*DepsRuntimeService` with `create*Service`
|
||||
|
||||
The barrel export (src/core/services/index.ts) re-exports 79 symbols from 28 files through a single surface, which obscures dependency boundaries. Consumers import everything from `./core/services` and can't tell which service file they actually depend on.
|
||||
|
||||
Establish consistent naming:
|
||||
- Exported service functions: `verbNounService` (e.g., `handleCliCommand`)
|
||||
- Deps factory functions: `create*Deps`
|
||||
- Consider whether the barrel re-export is still the right pattern vs direct imports from individual files.
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 All service functions follow a consistent naming convention
|
||||
- [ ] #2 Decision documented on barrel export vs direct imports
|
||||
- [ ] #3 No functional changes
|
||||
<!-- AC:END -->
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
<!-- SECTION:NOTES:BEGIN -->
|
||||
Naming convention consolidation should be addressed as part of TASK-27.2 (split main.ts) and TASK-27.3 (anki-integration split). As modules are extracted and given clear boundaries, naming will be standardized at each boundary. No need to do a standalone naming pass — it's wasted effort if the module structure is about to change.
|
||||
<!-- SECTION:NOTES:END -->
|
||||
|
||||
## Final Summary
|
||||
|
||||
<!-- SECTION:FINAL_SUMMARY:BEGIN -->
|
||||
Subsumed by TASK-27.2 and TASK-27.3. Naming conventions were standardized at module boundaries during extraction. A standalone global naming pass would be churn with no structural benefit now that modules have clear ownership boundaries.
|
||||
<!-- SECTION:FINAL_SUMMARY:END -->
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: TASK-8
|
||||
title: >-
|
||||
Reduce MpvIpcClient deps interface and separate protocol from application
|
||||
logic
|
||||
status: Done
|
||||
assignee: []
|
||||
created_date: '2026-02-11 08:20'
|
||||
updated_date: '2026-02-15 07:00'
|
||||
labels:
|
||||
- refactor
|
||||
- mpv
|
||||
- architecture
|
||||
milestone: Codebase Clarity & Composability
|
||||
dependencies: []
|
||||
references:
|
||||
- src/core/services/mpv-service.ts
|
||||
priority: medium
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
MpvIpcClient (761 lines) in src/core/services/mpv-service.ts has a 22-property `MpvIpcClientDeps` interface that reaches back into main.ts state for application-level concerns (overlay visibility, subtitle timing, media path updates, OSD display).
|
||||
|
||||
The class mixes two responsibilities:
|
||||
1. **IPC Protocol**: Socket connection, JSON message framing, reconnection, property observation
|
||||
2. **Application Integration**: Subtitle text broadcasting, overlay visibility sync, timing tracking
|
||||
|
||||
Separating these would let the protocol layer be simpler and testable, while application-level reactions to mpv events could be handled by listeners/callbacks registered externally.
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 MpvIpcClient deps interface reduced to protocol-level concerns only
|
||||
- [ ] #2 Application-level reactions (subtitle broadcast, overlay sync, timing) handled via event emitter or external listeners
|
||||
- [ ] #3 MpvIpcClient is testable without mocking 22 callbacks
|
||||
- [ ] #4 Existing behavior preserved
|
||||
<!-- AC:END -->
|
||||
|
||||
## Final Summary
|
||||
|
||||
<!-- SECTION:FINAL_SUMMARY:BEGIN -->
|
||||
Superseded by TASK-27.4 which absorbed this task's full scope (protocol/application separation, deps interface reduction from 22 properties to protocol-level concerns, event-based app reactions). All acceptance criteria met by TASK-27.4.
|
||||
<!-- SECTION:FINAL_SUMMARY:END -->
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: TASK-9
|
||||
title: Remove trivial wrapper functions from main.ts
|
||||
status: Done
|
||||
assignee: []
|
||||
created_date: '2026-02-11 08:21'
|
||||
updated_date: '2026-02-15 07:00'
|
||||
labels:
|
||||
- refactor
|
||||
- main
|
||||
- simplicity
|
||||
milestone: Codebase Clarity & Composability
|
||||
dependencies:
|
||||
- TASK-7
|
||||
references:
|
||||
- src/main.ts
|
||||
priority: low
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
main.ts contains many trivial single-line wrapper functions that add indirection without value:
|
||||
|
||||
```typescript
|
||||
function getOverlayWindows(): BrowserWindow[] {
|
||||
return overlayManager.getOverlayWindows();
|
||||
}
|
||||
function updateOverlayBounds(geometry: WindowGeometry): void {
|
||||
updateOverlayBoundsService(geometry, () => getOverlayWindows());
|
||||
}
|
||||
function ensureOverlayWindowLevel(window: BrowserWindow): void {
|
||||
ensureOverlayWindowLevelService(window);
|
||||
}
|
||||
```
|
||||
|
||||
Similarly, config accessor wrappers like `getJimakuLanguagePreference()`, `getJimakuMaxEntryResults()`, `resolveJimakuApiKey()` are pure boilerplate.
|
||||
|
||||
After TASK-7 (AppState container), many of these can be eliminated by having services access the state container directly, or by using the service functions directly at call sites without local wrappers.
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 Trivial pass-through wrappers eliminated (call service/manager directly)
|
||||
- [ ] #2 Config accessor wrappers replaced with direct calls or a config accessor helper
|
||||
- [ ] #3 main.ts line count reduced
|
||||
- [ ] #4 No functional changes
|
||||
<!-- AC:END -->
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
<!-- SECTION:NOTES:BEGIN -->
|
||||
Priority changed from medium to low: this work is largely subsumed by TASK-27.2 (split main.ts). When main.ts is decomposed into composition-root modules, trivial wrappers will naturally be eliminated or inlined. Recommend folding remaining wrapper cleanup into TASK-27.2 rather than tracking separately. Keep this ticket as a checklist reference but don't execute independently.
|
||||
<!-- SECTION:NOTES:END -->
|
||||
|
||||
## Final Summary
|
||||
|
||||
<!-- SECTION:FINAL_SUMMARY:BEGIN -->
|
||||
Subsumed by TASK-27.2 (main.ts split). Trivial wrappers were eliminated or inlined as composition-root modules were extracted. main.ts reduced from ~2000+ LOC to 1384 with state routed through appState container. Standalone wrapper removal pass no longer needed.
|
||||
<!-- SECTION:FINAL_SUMMARY:END -->
|
||||
Reference in New Issue
Block a user