Composition APIの開発でおすすめしたいことの記事

Composition API の開発でおすすめしたいことの記事

たまにはこういう初心に返った記事を読もうと思ったけど、こういう記事はもっと早く読むべきだった。

基本的に書いてあることについては同意で、自分がなんとなく感じていて言語化していない部分も分かりやすく説明されていてとてもよかった。

ちょっと前まではreactive派だったんだけど、最近はむしろref派になっていて、.valueのあるなしで苦戦したりしつつそれが解決されてきたので、分割代入でリアクティブ性を失うみたいな罠があるreactiveを使う必要性はないと思っている。

外部通信の結果を provide/inject で注入する

外部通信などに関する依存関係は inject / provide で注入することを推奨します。ここでは詳しく触れませんが、 storybook などを利用する場合などコンポーネント単体で動作させる時に、API クライアントなどを任意な値を返すものを provide することで、特定のユースケースの動作確認をしやすくなります。

API クライアントと通信し、その結果を返す関数をfetchXxxのような感じでuseXxx(この記事でいうコンポジション関数)の内部で宣言しているのだけど、このやり方で正しいかどうかは正直よく分かっていない。

provide/inject、バケツリレーの回避策的な意味合いで使うくらいの感覚しかなかったけど(そもそもバケツリレーを否定していないというか、バケツリレーは悪いことではないと思っている)、こういう「コンポーネント(UI)ともそれに紐づくロジックとも切り離したもの」の注入に使えばいいのだろうか？

API の通信はコンポーネントのロジックに紐づくかどうかは正直どっちともとれるけど、意味合いとしてはそういう感じかな。