Livewire 4の公式ドキュメントを日本語に翻訳しました。
今月から取り組む案件でLivewireを使うことになりました。もともとの開発基盤はLaravel + Inertia + Reactでしたが、そこからLivewireへの変更を提案し、採用されました。これを機会に、勉強ついでにドキュメントの日本語版も作ることに。Livewire 4を使い込むのはこれからなので要点のチョイスとしてはズレてるかもしれませんが、個人的に気になったところを紹介します！
Reactがあるのに、なぜLivewire？
最初にこの話を。Reactはクライアント側に状態を持つような複雑なUIを持つシステムを作るのが得意。たとえばCanvaやTrelloのようなサービスを構築できる。でもそこまで高度な状態管理を必要とする案件は実際は少ないのでは？
今回の案件は普通の業務システムに近い。それなら、Laravelの認証・認可、バリデーション、Eloquentなどを素直に使ってUIを作れるLivewireのほうが合っていると考えました。総合力で考えるとReactはそもそもフレームワークではないので片寄っている。
エディタのスクロールバーが縦に伸びがちなReact開発と比べると、だいぶ景色が変わります。シンプルなベストプラクティスが充実しているLaravel基準で実装パターンを揃えやすく、AIにもプロジェクトの前提を伝えやすそうです。
以下、Livewire 4の公式ドキュメントを読んで気づいたことについて。
Livewire 4ではSingle-file Componentが標準に
ドキュメントを読んでいて最初に気になったのが、Single-file Component（SFC）です。
Livewire 3では、PHPクラスとBladeを分ける構成が基本でした。
app/Livewire/CreatePost.php
resources/views/livewire/create-post.blade.php
Livewire 4では、PHPとBladeを1ファイルにまとめる Single-file Component がデフォルトになっています。
最初に見たときは「責務を分けたほうが分かりやすいのでは？」と感じましたが、よく考えると、検索フォーム、モーダル、小さな入力フォーム、一覧のフィルターなど、Livewireで作るコンポーネントにはそれほど大きくならないものも多いですね。粒度が小さい画面実装であれば、2ファイルを行き来するより、「このUIに関するもの」として1か所にまとまっていたほうが追いやすいケースもありそうです。
大きくなればMulti-file Componentや従来のclass-based componentも選択できます。Multi-file Componentに変換するconvertコマンドも用意されていて、至れり尽くせりですね！
なので、小さいうちはまとめて、大きくなったら分ける。 そういう選択がしやすくなった、と理解しました。
Islandsという考え方
もうひとつ、Livewire 4らしいキーワードだと感じたのがIslands（アイランド）です。
Islandsを使うと、ひとつのLivewireコンポーネントの中に、独立して更新される領域を作れるようです。
@island(name: 'stats')
<div>
{{ $this->stats }}
</div>
@endisland
コンポーネント全体ではなく、そのIslandだけを更新できます。
これまでは更新範囲を分けるために子コンポーネントへ切り出していた場面でも、Islandsで済むケースが出てきそうです。
実際の使い勝手はこれから確認しますが、コンポーネントを増やさず、必要なところだけ細かく更新できるという考え方は面白いと感じました。
サーバーサイド中心でも、必要なところだけリアクティブに
Livewireはサーバー側で状態を管理するので、操作するたびに通信する仕組みというイメージを持つ人もいるかもしれません。実際は、通常のwire:modelは入力するたびにサーバーへ同期するわけではありません。リアルタイムに同期したい場合は、
<input wire:model.live="title">
のように.liveを明示します。
この点においてLivewire 4では、非同期処理や遅延読み込みが強化されています。たとえばAsync Actionを使うと、通常は順番に処理されるアクションを並列実行できます。
<button wire:click.async="logActivity">
Track
</button>
ログ記録など、画面の状態変更とは切り離せる処理に使えそうです。
また、deferを使えば、重いコンポーネントを初回ページ表示のあとに読み込めます。
<livewire:revenue defer />
こうした機能を見ていると、Livewire 4では、
サーバーサイド中心の構成を維持したまま、必要なところだけフロントエンドらしい動きを取り入れる
という方向が、よりはっきりしてきたように感じます。
Single-file Component、Islands、非同期処理も、それぞれ独立した新機能というより、この方向で見るとつながって見えます。
AI時代に日本語ドキュメントを作る意味
公式ドキュメントを日本語に翻訳する意味はあるのか？改めて再定義しました。実装方法が分からなければAIに聞けますし、AIに読ませるだけなら英語の公式ドキュメントを直接参照させればよくて、むしろそのほうがAIの自走力を素直に生かせそうです。
それでも日本語版を作ったのは、技術を知り、理解し、採用を検討する入口として、日本語の情報には需要があると思っているからです。
新しい技術を提案されたとき、公式ドキュメントを開いて英語しかなければ、それだけで少しハードルを感じる人もいます。「日本で使っている人はいるのか」「問題が起きたときに対応できるのか」と不安になることもあります。
なので、自分は日本語ドキュメントあまり読まないしこんなことをしても本当は意味ないんだけどな～、とは思わないようにしています。
日本語ドキュメントは原本の更新に追従できるようにした
GitHub Actionsを使い、1日1回、英語版の原本に更新がないか確認するようにしました。
更新があれば日本語版との差分を確認し、翻訳を更新するPull Requestを自動で作成します。あとは内容を確認してマージすれば、翻訳サイトを更新できます。
英語版を定期確認
↓
変更を検出
↓
翻訳を更新
↓
Pull Requestを作成
↓
確認してマージ
スマホから確認してマージできるので、更新作業もかなり軽くできそうです。プルリク通知が届くのが楽しみです。
ちなみに、今回の翻訳作業そのものにもかなりAIを使いました。
途中から、翻訳というよりループエンジニアリングの実験のようになってしまったのですが、その話は長くなるので別の記事にします。手作業は最初の2～3時間だけで、全80ページの8割くらいは全自動でまわすことができたので、大成功でした。これだけのボリュームの翻訳を手作業で全部やると何か月もかかります。
まずは実際に使ってみます
ドキュメントを読んでいて感じたのは、Livewire 4はLivewire 3とまったく違うものになったというより、Laravelを中心にWeb UIを作るという考え方を、そのままもう一段進めたバージョンだということです。
Single-file Component、Islands、非同期処理なども、その方向で見るとつながって見えます。Laravel界隈は、仕組み化のセンスがいいと感じます・・
他にも、ページをまたいで状態を維持できる仕組みがありそうとか、画期的な改善がいろいろあるみたい。ちょうどこれから実案件で使うので、ドキュメントを読んだ印象と、実際に開発してみた感触がどう違うのか。使い込んでから書こうと思います。