第34章 Bridge Components

この章のねらい

Path Configuration（第33章）は、URL ごとの見せ方を決めるものでした。しかし、画面の中の一部分を、ネイティブの UI で表示したいこともあります。たとえば、ナビゲーションバーの右上に、ネイティブのボタンを置きたい、といった場合です。

それを実現するのが Bridge Components です。Web とネイティブの境界をつなぎ、Web の要素をきっかけにネイティブの UI を出します。この章では、その考え方を学びます。

34.1 Bridge Components とは

Bridge Components は、Web 側の宣言をきっかけに、ネイティブの UI 部品を動かす仕組みです。

たとえば、Web のフォームに「このフォームには送信ボタンが要る」と印を付けておくと、ネイティブ側がそれを受け取り、ナビゲーションバーにネイティブの送信ボタンを表示します。ボタンが押されると、ネイティブから Web へ「押された」と伝わり、Web がフォームを送信します。

Web とネイティブが、メッセージをやり取りして協調します。Web は「何が要るか」を宣言し、ネイティブは「それをネイティブの見た目で実現する」役割です。

34.2 Web 側のマークアップ

ここで効いてくるのが、第6部の Stimulus です。Bridge Components の Web 側は、Stimulus の controller の上に乗ります。

Web 側では、data-controller でブリッジ用の controller を要素に結びつけます。

<form data-controller="submit-button">
  ...
</form>

この submit-button という controller が、ネイティブ側へ「送信ボタンを出して」と伝えるブリッジになります。ブリッジ用の controller は、Stimulus の controller を、ネイティブと通信できるように拡張したものです（基底クラスや拡張の仕方は Hotwire Native のバージョンによります。詳細は付録Hと公式ドキュメントで確認します）。

大切なのは、Web 側はあくまで Stimulus の延長で書ける、という点です。第6部で学んだ controller の知識が、そのまま土台になります。

34.3 ネイティブ側の component

Web 側の宣言を受け取って、実際にネイティブの UI を出すのが、ネイティブ側の component です。

iOS なら Swift、Android なら Kotlin で書きます（第32章）。Web 側の submit-button controller に対応するネイティブの component を用意し、「submit-button が現れたら、ナビゲーションバーに送信ボタンを出す」といった処理を書きます。

Web 側の controller 名と、ネイティブ側の component が、名前で対応づきます。Web の宣言と、ネイティブの実装が、ペアになっている、と考えてください。

34.4 メッセージの送受信

Web とネイティブは、メッセージをやり取りします。

• Web → ネイティブ。「送信ボタンを、このラベルで出して」といった指示を送ります。ボタンのラベルや状態など、必要な情報を渡します。
• ネイティブ → Web。「ボタンが押された」といった出来事を伝えます。Web 側はそれを受け取り、フォームを送信するなどの処理をします。

この往復で、Web の状態（フォームの内容など）と、ネイティブの操作（ボタンのタップ）が、つながります。Web 側の受け取りは、ブリッジ用 controller のメソッドとして書きます。ここも Stimulus の延長です。

34.5 使いすぎを避ける判断

Bridge Components は強力ですが、使いすぎは禁物です。

何でもネイティブの部品に置き換えると、Web 側とネイティブ側の両方に実装が要り、二重管理になります。第32章の「すべてをネイティブ化しない」が、ここでも効きます。

判断は、こうです。Web の見た目で十分なら、ブリッジは架けない。ネイティブの部品でなければ実現できない、あるいはネイティブの方が明らかに体験が良い箇所だけ、ブリッジを使います。Relay の多くの画面は、ブリッジなしの Web のままで動きます。ナビゲーションバーのボタンのように、ネイティブの定位置に置きたいものだけを、ブリッジで橋渡しします。

もう 1 つ、忘れてはいけない前提があります。同じ Web ページは、ネイティブアプリの中だけでなく、通常のブラウザでも開かれます（Web-first）。ブラウザには対応するネイティブ component がないので、ブリッジは何も起こしません。だから、Bridge Components はプログレッシブ・エンハンスメントとして設計します。つまり、ネイティブがあれば良くなる、なくても Web だけで成立する、という形にします。先の例なら、Web 側に通常の送信ボタンを残しておき、ネイティブではそれをナビゲーションバーのボタンで置き換える、と考えます。こうすれば、ブラウザでもアプリでも壊れません。

第34章では、Web とネイティブをつなぐ Bridge Components を、Stimulus の延長として学びました。次の第35章では、Web ではなくネイティブ画面そのものが必要になる場面と、その責務分担を扱い、第9部を締めます。

参考資料

• Hotwire Native: https://native.hotwired.dev/
• Stimulus Handbook: https://stimulus.hotwired.dev/handbook/introduction