うしろのこの本ください

なんでもかきます

Vue3と書き物の悩み

今自分はいろいろあってVue3に対応している技術書の執筆を行っている。(やってることは言っても良いとなってる)(はず) が、色々なジレンマやこの先どうなるか想像がつかない領域での作業になるのでかなり方針に迷いが出ていてなかなか進まない。なので、ここにVue3関連の悩みを全部書き出して整理したい。めちゃくちゃに書き殴っているので読みづらい&文字だらけなのは許してください。

読んだら何ができるようになる本なのか

そもそもComposition APIはVueのメインを張る機能というわけでなく、Vueのリアクティブなしくみを提供する1つの手段なだけであってここに重きを置くのは初学者の理解を妨げる可能性がある。というのも、Vue3の本質はProxyによるリアクティブ化とかであってOptions APIとどっちが良い?みたいな話じゃなく、用途によって使い分けなきゃいけない。(と自分は思っているけど実際のところどうするのが良いのかわからない)

で、Vue3対応の技術書がどういう存在であれば役割を果たせるのかまだイメージがついていない。個人的には以下に該当するものは本来あるべき本の姿ではない気がしている。

  • Vue2からのマイグレートを中心に据えた内容
  • Composition APIの使い方を羅列する本
  • Options APIとComposition APIの違いを示した本

本当に読みたいのは実践でVue 3をどう使っていくと良いのかという知見ベースの話であり、これらは公式ドキュメントを読んだ方がどう考えても良い。ただ技術書となると使い方を書かないわけにもいかず、Options APIとComposition APIを混ぜて話を進めると読者の混乱を招くのは目に見えているのでComposition APIとはなにか、なぜ必要か、どう使うかは書くことになるし、なんならOptions APIについても記述しておいた方が親切…みたいなことを考えているとこの本の趣旨とかやりたいことってなんだっけ?ターゲットは?ってなる。

つまりは読者にある程度の知識を持っていることを期待するか、0ベースからの知識構築を支援するかでその本の方針が決まってくるという。どちらもカバーするのは半年程度で書ける内容ではない気もしている。(そもそもv3リリースから3ヶ月もたっていない)

などと考えつつ今はComposition APIについての項を粛々と書き進めていて、なるべくドキュメントからはわからない自分がコードを追ったりして得た知見を混ぜてやっている。ドキュメントを読め、コードを読めで済む話と頭で分かっていても書いておいた方がお得なのには変わりない。とりあえず読めばComposition APIの使い方がわかるし、Options APIを使ってた人はそれとの違いとか必要性がわかる、という方針でやっているが微妙にしっくりこない。

Composition APIって何が良いんだっけ問題

そもそもComposition APIは現状のOptions APIでカバーしきれない用途(大きなプロダクトにおけるコードベースの抽象化やロジック構成の関心の凝縮)を補うための存在でComposition APIを使うために既存の資産に手を入れるほどのものじゃないかもしれない。課題が見えていてComposition APIでそれが解決できるときに利用する手段の1つというポジション。ただ、すべてをComposition APIで記述するメリットというのもあって、例えばTSフレンドリーなコードにできるとか、バンドルサイズが小さくなるとか。と考えると0ベースならOptions APIは書かないのか?と言われると実際は怪しくて、Options APIにも良い面があるので実際どう書いてくのが良いのかまだコミュニティも分かってないという感じ。

Vueの最大の特徴はSFCで、通常そのコンポーネントが最悪でも(mixinsを利用していなければ)外部にそのロジックをシェアできない = コンポーネントに閉じ込める事ができるというある種のメリットがあった。コンポーネントは自身のcomputedであらゆるロジックを管理できて外への影響を考えなくても良かったが、Composition APIはそうではなく、シェアラブルなロジックを常に管理するというコストが発生する。というかそのために使うはずなので必然的に管理コストが高くなる。

VueのSFCは処理 + テンプレートをパターンとして切り出すことが苦手で、やることが増えるほどコンポーネントが肥大化していくし、コンポネを分割するにはファイルを増やさないといけないしReactのように右クリックでFC化みたいなことができないので分割するモチベが低いというのもある。Options APIは上記のように処理を閉じて自身の関心事をcomputedプロパティで管理していればよかったが、コンポーネントの分割ラビリティが低いままsetupに全てを自由に記述できます!みたいな状況になるとデカくていろんな外界と接続している複雑難解なコンポーネント爆誕するのは割と容易に想像できる。熟練のVue技術者であればslotを活用してうまいことやれるとは思うけど、やはりファイルをわけなければいけないという制約がモチベーションを下げていてどの現場もそれほど活用できていない印象がある。(自分がそんなに多くの現場をみたわけじゃないのでここは確証がない)

ともすれば、VueにSFC内で複数のコンポーネント(テンプレートとロジックを持つ何か)が定義できない状況でsetupのような高尚な機能が取り回し切れるのか?という疑問がでてくる。Options APIの時にはReactから輸入したPresentational/Container Componentパターンが定着し、うまいことやっていたがVue3時代にも何かコンポーネントを管理するための指針が必要な気がしてならない。ということでComposition APIはReact Hooksとは結構立場も違うよなと思ってたりもします。

jsxサポートへの期待など

VueでjsxするならReactやるぜという話は無限に聞こえてくるが、そもそもReactとVueのリアクティブシステムはしくみも開発者の責任範囲も違うためorで考えるものじゃない気がする。VueがjsxをやるメリットとしてはSFCを管理しなくて済むという1点だが、なかなかに強力で上記の肥大するsetupをうまくダイエットしつつ、テンプレート + ロジックのセットを細かく分解して外界接続による影響範囲を小さくすることができる。つまりはHooksと同じようなメリットを享受しちゃおうぜという話。ただこの話もまだ調査しきれていない部分が多くて、例えばvue templateはVueインスタンスに保持している特定のフラグを見る事でレンダリングを自動で最適化してくれるがjsxを使った場合それがちゃんと動作するのかわからない。VueとReactの最大の差は開発者がレンダリングに関心を持つのか、リアクティブステートに関心を持つのかなので、jsxを使う事でレンダリングの最適化に関しても面倒を見なきゃいけないみたいになるとVue自体がそれをサポートするAPIをあまり提供していないので話が難しくなってくる。ReactにはmemoやuseEffectがあるがVueにはないので。

Vueにおいてjsxを使うことは一生オプションで、技術書でメインになれないというジレンマがあって悩ましい。Vueを学ぼうと思ったらvue templateはコンポネの管理に難があるからjsxやります!って書いてあっても意味がわからないと思うのでしょうがないけど、そうしたらどこでこの話を解消すればいいんだろう…。

本当にこの辺りはロクに調べていなくて妄想で語っている節がある。@potato4d がVue + jsx(tsx)に関して詳しいので興味がある人はフォローとかしてみるとよさそうです。

終わり

そのうち誰かに相談するかも。有識者求む