😊

第8回 フロントエンドアーキテクチャを学ぶ

1 min read

読んだ記事

なぜ、Vue Composition APIを使うのか、理解する【メリット/デメリットまとめ】
相変わらず、Composition apiと戦っているので、そもそもなぜ我々がComposition apiを使うかというところから考えることにした。

内容の自分的解釈

結論:ロジックの分割、再利用性を高める非常に有力な剣だが、剣の力が強過ぎて、ハンドリングできない人間が取り扱おうとすると怪我をする。
Composition apiができた背景として

  • Vueで大規模な案件を作ることが起こるようになった
  • ロジックの膨れたコンポーネントが多くなった(Vueではコンポーネントが往々としてこうなる)

上記の問題でどのようなことが起きるかというと、肥大したコンポーネントではロジックの依存関係などが複雑かつコード量推測が難しく、保守や難しい、また、ロジックの切り出しを行える場所が存在していないことから増幅を止める手段がないと言う状態でした。
(SFC、単一ファイルコンポーネントによるメリットであり、デメリットである。template、logic、stateの全てがこのSFCに書けるが、ロジックなどの共有ができないと言うデメリットも抱えている。)
Composition apiはそんなコンポーネントからlogic、stateを切り出すことで、

  • SFCはViewについてのみを関心事とできる
  • logic、stateはcomposableが責務として負う
  • logic、stateを切り出したことで共有化ができる

というメリットを受けられる。
かつてのように、意味がわからないくらい肥大したSFCコンポーネントを前に膝を折る必要がなくなるのである。
が、当然デメリットはある。

  • Composition apiを手に取ると言うことは、今までのVue、Nuxtの制限の外に出て、新しい世界(アーキテクチャ)へ飛び出すと言うこと
  • 何も知らない子供が持つにはあまりにも難しいこと

以上のデメリットを要約すると、「自由度が生まれすぎる」ということです。
Nuxtをベースとして考えると、npx create-nuxt-appとコマンドを打った後、まずディレクトリに「composables」などというものがまず存在しない。
Nuxtというフレームワークは「これだけあれば、ひとまずアプリを作れるよ」という機能(ディレクトリ)を実装者に提供する。が、そこに存在していない、いわゆる管理外の何かがcomposableになるのだ。
つまりここからは我々が

  • どのようにcomposableを使い
  • どのような制限を立て
  • どのように複雑化を避けるか

といったこと、つまり「アーキテクチャ」を考える必要があるのだ。
Vue3も誕生してからそこそこたち、また、Nuxt3についても発表、Compositon apiの正式採用もされた(Nuxt2系まではnuxt composition apiをlibとして追加しないとそもそも使うことができなかった)が、それでもcompositon apiをどのように使うかは未だ定まっていない、ベストプラクティスとして定めるかも時期尚早だろう。
なので軽い気持ちでcomposition apiに手を出すべきなのか、個人的にはNoと言いたい。

感想

アーキテクチャを勉強するきっかけになった、Composition apiへまた帰ってきた。
依存関係や、関心事の分割という点ではやはりとても力を持っているとは思う。
(以前学んだクリーンアーキテクチャの文脈でも、これ自体は正しいとも思う。ページViewは柔らかい=変動性があるが、ロジックはコンクリートなものであったりするので。)
が、その強力な力を使うために制御する力(=アーキテクチャ)も必要で、思考なしに使うことの影響の大きさを今現在進行形で感じている。
その場その場で最適解を出すしかないのだろうが、その最適解を出す手がかりだけでもモテるようになりたいと思った。

Discussion

ログインするとコメントできます