先日 Kaigi on Rails 2025 で登壇しました。 登壇内容の相談や、会社で何回も練習に付き合っていただいてありがとうございました。 特に id:kozy4324 や id:kiryuanzu にはとてもお世話になりました。
資料に盛り込めなかった話の補足や反響に対する私見を載せます。
当日のTwitterの反応
反響への回答
custom element へのデータの渡し方が複雑じゃない？
custom element へのデータを渡すインターフェースは、HTML属性 と DOMプロパティ の2つです。発表では渡したいデータ型によって使い分けるように説明しましたが、どちらかに統一できた方がシンプルだとは思います。
仮に HTML 属性に寄せたい場合は、コンポーネント側で文字列を型キャストする必要があります。Angular なら transform という API が用意されています。
入力プロパティによるデータ受け入れ • Angular 日本語版
ただ、この型キャストもプロパティごとに実装するのが面倒になりそうだったので採用しませんでした。
その代わり、DOM プロパティを利用して JavaScript 側から直接値を渡しました。これなら文字列以外も扱えます。 ただし、この方法は inline script が必要になるため Strict CSP（特に script-src 'self'） が使えません。*1
CSP によりセキュリティを担保したい場合は、DOMプロパティは使いづらいと思います。
今回 custom elements を採用したのは新規サービスであり、コードベースも小さいです。そのため、セキュリティ的にまずいコードが混入しないようにレビューで担保できるので成立していると思っています。
データ属性に配列やハッシュを入れるとき、もっと良いサニタイズ方法はない？
正直なところ、現状は難しいと思います。サニタイズしつつ、ちゃんと動作するコードにするには少なくともの要件を満たす必要があります。
- HTML として正しいこと
- JavaScript として正しいこと
- ERB（Ruby）として正しいこと
この条件を同時に保証する API はなく、自前で作るのも大変です。なので「data 属性に文字列として入れて、JavaScript 側で JSON.parse する」のが現実的だと思います。
もし属性が増えて管理が面倒なら、script 要素に逃げるのではなく HTML 属性の工夫で対応するのが良いと考えています。*2
custom element を自作するとメンテナンスコストが高くない？
ここは設計次第です。うまくカプセル化できれば再利用性も高く、コストは抑えられます。逆に安易に作るとコストは増えます。
また、そこまで作り込むなら Hotwire で自前実装するのも選択肢です。私たちのチームは Angular の知見を持つメンバーが多かったので、custom element 化することで既存の知識を活かせるメリットがありました。チームのスキルセットや環境によって最適解は変わると思います。
こぼれ話
今回初めての登壇で半分病みかけながら、準備をしました。できうる準備はして望めたので、それは良かったかなと思いつつ、今後に活かしたい改善も見つかりました。そのあたりは別でまとめるかもです。
いろんな方に声掛けられまして、「初めて custom elements 知った」「今度使ってみたいといった」声を届けてくれた方々がいて嬉しかったです。 登壇者は正直大変でしたが、その分コミュニティと繋がれた感覚が味わえて、またやりたいなと純粋に思いました。
あとは、懇親会で大倉さんとお話しできる機会がありまして、採択理由やコミュニティの話ができました。今後も Web 標準を追っていくモチベーションが湧きましたし、コミュニティや勉強会を主催したくなりました。*3 ありがとうございました。
色んな人と話して自分もコミュニティ欲しかなった。多摩でやるかー！
— daichi (@da1chi24) 2025年9月27日
同世代のレベル高い発表を見て、刺激ももらいました。自分も今日から良い発表ができるように日々の活動頑張ります。
最後に、Kaigi on Rails を主催していただいたオーガナイザーの皆様ありがとうございました。
