トーク

React 19はServer Components・Actions・Suspenseの刷新により、データフェッチからレンダリングまでの体験を一変させました。しかし同時期、Rust製のoxfmtをはじめとする「高速・単機能」ツール群が既存エコシステムを塗り替えつつあります。見落とされがちな問題があります。ライブラリ本体の進化とツールチェーンの進化は同じ速度では進まないということです。新しいレンダリングモデルに最適化されたlintルールはまだない、CIの前提が変わっているのにパイプラインは旧来のまま──こうした「ズレ」がチームの開発体験を静かに蝕みます。本セッションでは、この1年のReact周辺とフロントエンドツールの動向を俯瞰し、両者のギャップをチーム開発・モノレポ構成・CI設計でどう埋めるかを具体事例とともに考えます。「最新を追う」だけでは得られない地に足のついた設計指針をお届けします。

「重い計算処理の速度もメモリ効率もWasmが良い」という直感から、zip圧縮モジュールをWasm（Rust）で自作をしました。しかし、実際に使ってみると、既存のJSライブラリ（JSZip）のほうが使い勝手が良いという結論に達しました。
なぜJSライブラリのほうが良かったのか？というところをWasmの制限を絡めて紹介をします。
最後に、それでも私がWasmを使いたい理由についても語ります。

リファクタリングによるデグレーションは、機能は正しく動いているのに体験が劣化するという、テストでは捕捉しにくい領域で起こります。
ユーザーからの問い合わせが届く前に検知したい。しかし、すべての指標を監視するのは現実的ではありません。
本LTでは、「ユーザーの体験に悪影響を与えるか？」を基準に監視対象を絞り込む設計指針と、その基準をもとに筆者が実際にどのように指標を選定し運用したのかを紹介します。
特定の技術スタックに依存しない設計思想の話なので、どなたにも持ち帰れる内容です。リファクタリングに限らず、日々の開発で「何を監視すべきか」を判断するためのヒントになればと思います。

モバイルアプリユーザーの約25〜35%が、OS設定で文字サイズを標準以外に変更していると言われています。
この設定で文字サイズを変更している場合に、アプリ内のWebViewだけ文字サイズが変わらないことがあります。

実は、iOSならCSSの font: -apple-system-body;、Androidならネイティブ側の textZoom 設定を橋渡しすることで、Web側にもOSの文字サイズ設定を反映できます。

このとき重要なのが、文字サイズの変化を前提としたレイアウトです。 rem によるスケーリングはもちろん、文字量に応じて高さが伸びる設計や、要素が溢れた際の柔軟な折り返しなど、拡大を許容する実装が必要になります。 OSの設定をどう受け止め、UIを最適化するか。 境界を越えた実装Tipsを共有します。

ライブラリを使わず <input type="file"> を用いて実装されたファイルアップロード機能を扱った際、 macOS から送信されたファイル名だけがサーバー側の検索と一致せず、データ取得に失敗する問題に遭遇しました。

見た目は同じ文字列でも、 OS や入力経路（フォルダ選択・テキスト入力）の違いによって内部表現（NFC / NFD）が異なる場合があります。今回の問題は、その差異がブラウザを経由してアプリケーション層まで持ち込まれていたことが原因でした。

本トークでは実際の再現手順を示しながら、この不整合がどのように発生するのかを整理します。その上で、ブラウザ標準APIでファイルアップロードを実装する際に、どの境界で正規化や比較責務を持つべきかという設計判断を取り上げます。

環境差異に依存しない、堅牢なアップロード実装のプラクティスを持ち帰っていただくことを目指します。

Reactコンポーネントのテストで広く使われるJSDOMは、ブラウザ環境の代用品であり、レイアウト・イベント・非同期処理などで実ブラウザと差異があります。「テストは通るのに本番で動かない」問題が起こり得ます。
Vitest Browser Modeは実ブラウザ上でテストを実行するアプローチです。本トークでは、Testing Libraryからの移行を通じて見えた技術的な違いを深掘りします。

非同期アサーション: expect.element()とリトライ設計の関係
userEventのAPI設計: setup()が不要になった背景
イベント処理の違い: JSDOMで見逃される実ブラウザ特有の挙動
レンダリングと副作用: DOM APIやイベントループにより異なるuseEffectの振る舞い

JSDOMの限界、実ブラウザテストのトレードオフ、選択基準を実例とともにお話しします。

リセットCSSは、ブラウザが標準で持っている要素ごとのデフォルトスタイルを揃えるためのプラクティスとして広く知られています。
一方で、一度組み込むと見直す機会が少なく、古い指定がそのまま残ることもあります。

歴史あるアプリケーションのアクセシビリティ向上に向き合う中で、デザインシステムの適用でも漏れがちな古い画面の改善策を考えた結果、リセットCSSの「たった1行」を削除するだけで改善につながった、という出来事がありました。
このトークでは、なぜその指定が入っていたのかを整理しつつ、現在のブラウザ事情では何が問題になりやすいのか、そしてリセットCSSを見直すときの観点を紹介します。

ZodをフォームバリデーションやAPIレスポンスの検証に使っているチームは多いと思います。そんなZodですが、近年はバリデーション専門というより、データ変換ライブラリとしても進化してきました。私もパイプラインを書いたのをきっかけに、「バリデーションのついでにデータ整形もやってしまおう」という考えが加速しました。

しかし便利さに頼るうち、スキーマ定義のチェーンがビジネスロジック化したり、スキーマを読むだけでは処理の全容が追えないコードになってしまいました。チームから「処理の流れが追えない」「便利そうだけどよく分からん」と言われたこともありました。

本発表では、フロントエンドのスキーマ定義で便利だった実装と、苦しくなった実装を、実際の声と共に紹介します。スキーマに書くべきことと、普通の関数に切り出すべきことの判断基準を、自分なりの失敗から共有します。

みなさん、フォームをどのように実装していますか？

たくさんの選択肢がある中で、
「Web標準なフォームならシンプルで軽量」
そう信じて Conform を選択しました。

しかし、1万 input を超える大規模フォームの要件の前で、その理想が崩れます。
本LTでは、大規模フォーム開発で直面した課題と、そこから学んだフォームの技術選定における判断軸についてお話しします。

私が書いた import ... assert { type: "json" } のコードは、ある日書き換えを迫られました。

仕様策定を担うTC39でStage 3まで進んだImport Attributesのキーワードが、assertからwithに変更されたためです。
Stage 3は採用してもほぼ安全。その思い込みが崩れた瞬間でした。なぜこの変更は起きたのか。TC39ではどのような議論が行われているのか。実体験をもとに追いかけます。
このLTを通じて、普段は遠い存在に感じるTC39やECMAScriptの仕様策定プロセスに関心を持つきっかけになれば幸いです。