背景
セッション 26 の C 軸 (アーキテクチャ) 探索で同定された Tier 2 (運用補強、「育ったら着手」系) refactor 候補を 1 件の backlog issue としてまとめる。
Tier 2 の判定基準: 「現状動作問題なし、refactor cost は低中、ただしコードベースが育ったらメリットが出るタイプ」。v0.6.0 では着手しない。育ったタイミング (= 各 trigger 条件を満たした時) で個別 issue に分割して着手する。
Tier 1 (v0.6.0 で着手): #206 (useShallow) / #207 (2 モード e2e 重複) / #208 (settings schemaVersion) — 別 issue。
Tier 2 一覧
1. preload 53 メソッド hardcode の 2 ファイル同期 lint rule
- ファイル:
electron/preload/api.ts (型) + electron/preload/index.ts (実装)
- 現状: 53 メソッドを 2 ファイルに hard-code、新規追加時に両方修正が必要
- 改善案:
api.ts の型 key と index.ts の object key の count が等しいことを check する lint rule (15 分以下で書ける) または docstring で順序明記
- trigger 条件: preload API が 70 メソッド超え、または churn 月 5 件超え
2. live-preview の共通 helper 集約 (D2 + D5)
- ファイル:
src/components/editor/live-preview/* (11 ファイル) + src/components/editor/live-preview/math.ts:104-111
- 現状:
- D2:
for (const { from, to } of view.visibleRanges) { tree.iterate(...) } パターンが 11 ファイルで重複
- D5:
math.ts の collectCodeRanges() が毎回全文 iterate (large doc で性能ヒット可能性)
- 改善案:
lib/live-preview-helpers.ts に iterateVisibleRanges(view, callback) を抽出
collectCodeRanges を StateField cache 化、または tree update 時のみ rebuild
- trigger 条件: live-preview デコレーション 15+ に増えた / large doc (50KB+) で math 描画が体感重い
3. e2e mock 741 行のロジック同期漏れ検出
- ファイル:
e2e/helpers/electron-api-mock.ts (741 行) + electron/main/ipc/search.ts:106 等
- 現状:
searchFiles の fuzzyMatch / scanUnresolvedWikilinks の正規化ロジックが mock 側に inline コピーされている。main 側を変えると同期漏れリスク
- 改善案:
- 候補 A: 純関数化 (
electron/main/utils/search-pure.ts) して mock も import
- 候補 B:
__testing export pattern (electron/main/ipc/fs.test.ts:23 の前例) を mock 用にも定義
- trigger 条件: e2e spec 40+ 件 / main 側 search ロジックの変更頻度上昇
着手方針
このまま放置し、各 trigger 条件を満たした時に 個別 issue を作成して着手 する。本 issue は backlog としてのみ保持。
trigger 条件を満たしたか否かは、v0.6.0 リリース後 (Tier 1 着手後) に再評価。
完了条件 (この backlog issue の close 条件)
関連
背景
セッション 26 の C 軸 (アーキテクチャ) 探索で同定された Tier 2 (運用補強、「育ったら着手」系) refactor 候補を 1 件の backlog issue としてまとめる。
Tier 2 の判定基準: 「現状動作問題なし、refactor cost は低中、ただしコードベースが育ったらメリットが出るタイプ」。v0.6.0 では着手しない。育ったタイミング (= 各 trigger 条件を満たした時) で個別 issue に分割して着手する。
Tier 1 (v0.6.0 で着手): #206 (useShallow) / #207 (2 モード e2e 重複) / #208 (settings schemaVersion) — 別 issue。
Tier 2 一覧
1. preload 53 メソッド hardcode の 2 ファイル同期 lint rule
electron/preload/api.ts(型) +electron/preload/index.ts(実装)api.tsの型 key とindex.tsの object key の count が等しいことを check する lint rule (15 分以下で書ける) または docstring で順序明記2. live-preview の共通 helper 集約 (D2 + D5)
src/components/editor/live-preview/*(11 ファイル) +src/components/editor/live-preview/math.ts:104-111for (const { from, to } of view.visibleRanges) { tree.iterate(...) }パターンが 11 ファイルで重複math.tsのcollectCodeRanges()が毎回全文 iterate (large doc で性能ヒット可能性)lib/live-preview-helpers.tsにiterateVisibleRanges(view, callback)を抽出collectCodeRangesを StateField cache 化、または tree update 時のみ rebuild3. e2e mock 741 行のロジック同期漏れ検出
e2e/helpers/electron-api-mock.ts(741 行) +electron/main/ipc/search.ts:106等searchFilesの fuzzyMatch /scanUnresolvedWikilinksの正規化ロジックが mock 側に inline コピーされている。main 側を変えると同期漏れリスクelectron/main/utils/search-pure.ts) して mock も import__testingexport pattern (electron/main/ipc/fs.test.ts:23の前例) を mock 用にも定義着手方針
このまま放置し、各 trigger 条件を満たした時に 個別 issue を作成して着手 する。本 issue は backlog としてのみ保持。
trigger 条件を満たしたか否かは、v0.6.0 リリース後 (Tier 1 着手後) に再評価。
完了条件 (この backlog issue の close 条件)
関連