refactor: Vue コンポーネントの watch を store.watch に移行する

[Hiroshiba]

内容

#2994 で store.watch が使えるようになるので、Vue コンポーネントで store の state を監視して store の action を呼んでいる処理を store.watch に移行するリファクタリングissueです。
各ファイルは独立した作業なので、どれか1つから取り組めます。

対象:

1. src/components/App.vue（ソングの再生デバイスを同期する watchEffect）

   • store.state.savingSetting.audioOutputDevice の変化を監視して APPLY_DEVICE_ID_TO_AUDIO_CONTEXT を呼んでいます

2. src/components/Sing/SingEditor.vue（トラック数が1から増えたらサイドバーを開く watch）

   • store.state.tracks.size の変化を監視して SET_SONG_SIDEBAR_OPEN を呼んでいます

3. src/components/Talk/TalkEditor.vue（代替ポート情報の変更を監視する watch）

   • store.state.altPortInfos と store.state.isVuexReady の変化を監視して SHOW_NOTIFY_AND_NOT_SHOW_AGAIN_BUTTON を呼んでいます
   • この処理は isVuexReady のガード条件や confirmedTips の参照が含まれるため、移行先のストアモジュールや実装方針を先にこの issue でコメントして相談すると良さそうです

Pros 良くなる点

• state の変化に対する副作用の呼び出し元が store 側に集まり、コンポーネントのライフサイクルに依存しなくなります

Cons 悪くなる点

特になし。

実現方法

#2994 で singingStore に追加した singingStorePlugins と同様の方法で実装できます。
各ストアモジュールの plugins として export し、src/store/index.ts でまとめます。

[Akikukeo1]

@Hiroshiba

Akikukeo1#11
で、WatcherをPluginに移行する案を試しに実装してみました（検証用のPRです）。

ただ、TalkEditor依存のロジックについて設計方針をどうするべきか迷っています。

PRではPluginとしてグローバルに登録していますが、従来はTalkEditorのライフサイクルに紐づいていたため、挙動が変わってしまう可能性があります。

現状は以下の2案で考えています

1. Pluginとしてグローバルに持つ（現在のPRの実装）
2. TalkEditorにスコープして、従来の挙動を維持する

個人的には「挙動を変えない」方針であれば②の方が安全だと考えていますが、このケースでは1のようにグローバル化する設計の方が望ましいでしょうか？

[Hiroshiba]

バグがなさそうであればどちらでも大丈夫な気がしています！！
どちらでも良いならstore.watchの方が綺麗に感じるかな～と！

@sevenc-nanashi さん的にどうでしょう？

[Hiroshiba]

ping @sevenc-nanashi