【ITニュース解説】Skip Livewire? Why Laravel Blade + AQC + Alpine Might Be All You Need

現代のWeb開発において、ユーザーが操作するとすぐに画面が更新されるような、動きのあるインターフェース（UI）を作ることは一般的である。Laravelという人気のWebフレームワークを使っている開発者にとって、Livewireはこのような「リアクティブUI」を、Vue.jsやReactといった本格的なフロントエンドフレームワークをすべて書くことなく実現できる便利なツールとして広く知られている。Livewireは、フロントエンドとバックエンドの技術をうまく連携させてくれるが、それが常に最適な選択肢であるとは限らない、というのがこの記事の筆者の主張である。

筆者は数年間、ビジネスロジックを最優先に考えたLaravelのアーキテクチャを洗練させてきた。このアプローチは、コードが整理され、テストしやすく、再利用可能で、余計なフレームワークに依存しないという特徴を持つ。筆者の方法は、主に三つの核となるツールを組み合わせる。一つ目は、ビジネスロジックを整理するための「AQC（Atomic Query Construction）」、二つ目は、画面の一部を動的に更新するための「Blade Partials + Fetch API」、そして三つ目は、軽い動きをUIに加えるための「Alpine.js」である。筆者は、これらのツールを適切に組み合わせれば、Livewireは不要になると考えている。

まず、バックエンドの処理についてである。筆者は、AQCパターンを使ってバックエンドのロジックを「原子的な（atomic）クラス」という小さな単位で整理している。ここでいう「原子的なクラス」とは、例えば、特定の条件で投稿を一覧表示したり、フォームの送信処理を行ったりといった、一つの特定の機能だけを担当するクラスのことである。Livewireの場合、ロジックをコンポーネント（部品）のメソッドの中に書くことが多い。しかし、AQCを使えば、ロジックを個別のクラスとして明確に分離できるため、コントローラー（リクエストを処理する場所）、API、さらにはBladeの部分ビューからデータを取り出す際にも、同じロジックを重複して書くことなく再利用できる。同じ処理をLivewireのクラスの中で再び書く必要がなくなるというわけである。

次に、ユーザーが目にする画面（ビュー）の処理についてである。筆者のアプローチでは、Bladeの部分ビューを、コントローラーが処理する通常のWebページのアドレス（ルート）を通じて返す。これらの部分ビューは、すでにユーザーの認証状態を確認し、入力データの検証を行い、Bladeの機能を使って特定の条件に基づいて表示内容を制御できるようになっている。そして、これらはウェブページの一部としてそのまま組み込む準備ができているのである。この方法の良い点は、通常のLaravelの書き方で開発できること、Livewire特有の構文（wire:modelのようなもの）を学ぶ必要がないこと、そして、他の通常のルートと同様にデバッグできることである。JavaScriptのfetch()関数を使うだけで、Livewireが提供するwire:clickやwire:model、wire:submitといった特別な記述のほとんどが不要になる。

そして、UIに動きを加える部分にはAlpine.jsを活用する。タブの切り替え、モーダルウィンドウの表示、ドロップダウンメニュー、リアルタイムに数字が変化するカウンターなど、ウェブページの軽いインタラクティブな要素にはAlpine.jsで十分に対応できる。Alpine.jsは、ReactやVue.jsのような「仮想DOM」という複雑な仕組みを持たず、「ライフサイクル」と呼ばれるコンポーネントの状態管理も不要である。HTMLの中に簡単なJavaScriptの記述を少し加えるだけで動作する。さらに良い点として、Alpine.jsはBladeの部分ビューやFetch APIで挿入されたコンテンツと干渉することなく、シームレスに機能する。

Livewireも同様の機能を提供するが、筆者はそこに「コスト」があると指摘する。LivewireはLaravelの既存の構造の上に「追加の層」として加わる。この層は、JavaScriptを書きたくない開発者や、ロジックをコンポーネントクラスの中に置くことに抵抗がない開発者、あるいは筆者のような「バックエンドファースト」な設計をまだ採用していない開発者にとっては非常に便利である。しかし、もしアプリケーションが既にAQCのようなクリーンな方法で構築され、責任の分離が適切に行われている場合、Livewireを導入すると既存の強力なLaravelの構造を活かせなくなり、同じようなロジックを重複して記述することになる可能性がある。これはJavaScriptを書くのを避けるために余計な作業を増やしてしまうことになりかねない。

筆者のアプローチも常に進化している。例えば、画面に表示されたときにだけ部分ビューを読み込む「IntersectionObserver」を使った遅延読み込み、頻繁に使う部分（ドロップダウンの選択肢など）は一度レンダリングした部分ビューをキャッシュする、時間のかかるバックグラウンド処理にはAQCとLaravelの「Job」機能を組み合わせる、HTMLの部分ビューを使ってページ遷移をスムーズにするTurbo/Hotwireのような技術を活用するといった方法で、さらに改善を進めている。

結論として、Livewireが決して悪いツールだと言っているわけではない。BladeとVue.jsの間を埋めるようなツールを必要とするチームにとっては素晴らしい選択肢である。しかし、もしすでにLaravelをクリーンな方法で開発しており、機能ごとに適切な分離ができているのであれば、Livewireは解決する必要のない問題を解決しているだけかもしれない。筆者が提唱する、コントローラー、AQC、Blade、Alpine.jsを組み合わせたスタックは、より理解しやすく、テストが容易で、Laravelの標準的な機能と親和性が高く、開発者自身がすべてを完全にコントロールできるという利点がある。これが、筆者がLivewireを使わない選択をした理由であり、場合によっては他の開発者も同様の選択を検討する価値があるというメッセージである。