トーク

振る舞い駆動開発（BDD：Behaviour-Driven Development）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。

本セッションでは、TypeScriptでBDDを始めるための基本的な考え方と実践方法を紹介します。Cucumber.jsなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。

TypeScriptでテストを書いて、これからBDDを始めたい方に向けてわかりやすく解説します。

React Server Functions をインラインで定義した場合、コンポーネントのレンダリング時の値にアクセスすることができます。

しかし、Server Functionsは実際はただのAPIエンドポイントであり、本来はステートレスな存在のはずです。

ステートレスなのに、なぜレンダリング時の値にアクセスできるのか、実際のフレームワークの実装を参照しながら説明します。

const Component = () => {
const now = new Date().getTime()
const fn = () => {
"use server"
console.log(now) // ここでnow（レンダリング時の時刻）にアクセスできるのはなぜか？
}
...
}

多くのプロジェクトで、index.tsを用いてexportやimportを管理していると思います。

デフォルトで多くのプロジェクトに入っているため、議論の対象になりづらいですが、index.tsは複数のモジュール・コンポーネントを一括でエクスポートするために使われる以上に、モダンなフロントエンドのディレクトリ構成による設計の表現を成立させるために重要な役割を担っています。

特に、循環参照を発生させないように参照を容易に管理したり、ディレクトリの外から呼び出されるコンポーネントと、ディレクトリ内部でのみ使用されるコンポーネントを適切に分離しカプセル化を行うために有用です。

本トークを通して、index.tsを切り口としてディレクトリの設計思想へ触れる糸口になれば幸いです。

折り紙の折り方、分かりづらくないですか？
私たちのプロダクト「OriCube」は、この課題を解決します。

OriCubeは、折り紙の折り方を3Dモデルを用いて視覚的に表現したwebアプリケーションです。
折り紙の折り方を確認するだけでなく、ユーザーがweb上で折り紙の折る手順を投稿することができます。

本LTでは、「折り紙を折る」という体験をweb上で再現することで得られた、ReactとThree.jsを組み合わせたインタラクティブな3D表現のノウハウをお伝えします。
特に、3Dモデルの動的制御の実現、複雑な3Dシーンにおけるパフォーマンス最適化に関して話します。

OriCubeは、JPHACKS2024で最優秀賞, 聴衆投票1位を獲得しました。

みなさんlint,formatはpre-commitに入れていますか？
commitに時間がかかるのは生産性がとついついCIのみになっていてlint,formatのコミットが生えるなん、レビュー待ちだと思ったら落ちていたなんて悩みはありませんか？
私はエンジニアとして2社3プロジェクトでPrettier＋ESLintからRust製高速ツールBiomeへ移行し、この悩みを解消しました。
PrettierをBiomeのformatterに、ESLintルールのうちBiome対応分だけを置き換えるハイブリッド構成を用いてこの悩みを解消した経緯や結果についてお話しします
カスタムルールなど移行困難な部分はESLintを残しましたが、formatは従来比10倍超、lint全体も約5倍高速化し、CIとpre-commitの待ち時間を大幅に短縮。発表では移行手順、運用上の注意点を事例を元に共有します。

最近注目され、便利な UI を簡単に実装できる Popover API ですが、その手軽さの裏にはアクセシビリティの落とし穴が潜んでいるかもしれません。特に、新しい WCAG 2.2 の達成基準を考慮すると、これまで見過ごされてきた問題がクリティカルになる可能性があります。
このセッションでは、 Popover API を利用する際に特に注意すべき WCAG 2.2 の達成基準をピックアップし、具体的なコード例を交えながら、よくある実装のつまずきどころと、それを乗り越えるための実装のヒントを共有します。

現代のウェブアプリケーション開発において、セキュリティは単なる追加機能ではなく、開発の初期段階から組み込むべき必須要件といえます。Agentic CodingやVibe Codingと呼ばれるような生成AIを活用したコーディングの現場においても、静的解析ツールでのリンティングがより重要視されるだろうと考えます。
このトークでは、特にWebフロントエンドにおけるセキュアコーディングをサポートするESLintプラグインに焦点を当てます。それらのルールセットがセキュリティリスクをどのように検出するかを紐解き、フロントエンド開発の文脈でどのように応用可能かを示します。

新卒フロントエンド開発者の私が、最近ブラウザに導入されたif()/else、:has()、@supports、コンテナクエリといった最新のCSS機能を紹介しつつ、「JavascriptなしでどこまでインタラクティブUIを作れるか」を5分で解説するセッションです。
モーダルやアコーディオン実装などCSSだけで実現可能なUIパターンを見せながらJavascriptを使わない選択肢があるということをお伝えします。またパフォーマンス＆互換性の最適化ポイント、CSSとJavascript実装それぞれのサイズ＆速度比較もコンパクトにお届けします。
最新CSS機能がどういう風に使われてるのかを知りたい方や、CSSプロトタイピングやJavascript以外の選択肢に興味がある方に最適です。

新卒としてフロントエンド開発に飛び込んだ私が、スピードと1px単位で再現する丁寧さを掛け合わせたTailwind CSSのユーティリティファースト思想を武器に、Figmaで作成されたデザインカンプ通りのピクセルパーフェクトUIを実現するワークフローをご紹介します。
複雑なカスタムCSSを極力排除し、すべてのレイアウト・余白・カラーをユーティリティクラスで厳密に制御することで、保守・管理しやすいコードを実現。vw/vhベースのレスポンシブサイズ指定や、ブレイクポイントごとの細かな微調整、各ブラウザ間のレンダリング差異検証と補正対応など、プロダクション品質のUIを効率よく丁寧に構築するためのベストプラクティスを学ぶことができます。
新卒だからこそ試行錯誤して実現した、モダンCSS運用の最短ルートをお伝えします!

昨今のWebフロントエンドは非常に高機能化し、一つの画面で多数のリッチな機能が提供されることが多くあります。
各機能が適切に動いているかを担保するため、ついE2Eテストに甘えたくなることもあるでしょう。

しかし、E2EテストはAPIなどの外部システムに依存するため、低速で不安定になりやすいことから、運用は修羅の道です。
一方、単体テストで担保する場合、状態や副作用を多く抱えるモジュールの単体テストのためには複雑なセットアップが必要で、本質的でなく良くわからないテストが増えて惰性で運用しがちです。

そのような課題に対して、APIをモックした状態でPlaywrightを活用する、E2Eテストと単体テストの良いとこ取りを実現した「フロントエンド統合テスト」を導入しました。OpenAPIに基づいて型安全にAPIをモックしたり、AIによって自動生成するといった工夫についても紹介します。

みなさん、タプルを map() にかけると戻り値が普通の配列型になることをご存じでしょうか？

Promise.allSettled() で複数の API を並列実行し、成功なら value、失敗なら null に変換しようとした際にこの落とし穴にハマりました。 TypeScript の実装で map() の戻り値は常に U[] になるように型定義されているため、タプル長と要素型が失われてしまうのです。

そこでタプルを map() にかけても返り値をタプルにするために、mapped type と Awaited を組み合わせ、引数に渡したタプル型から戻り値の型を動的に生成し、map() 後でもタプル型を維持する関数をつくりました。

今回はその工夫の詳しい内容を共有します！Typescript で開発されている方にはお役に立てると思います！！

近頃、V8やJavaScriptCore、SpiderMonkeyのようなメジャーなJSエンジン以外にも新しいJSエンジンのプロジェクトがいくつか進んでいます。

また、自作のJSエンジンを含めた自作ブラウザを作るような書籍も出版されており、JSエンジンへの興味を持ちやすく、理解への敷居も多少は下がりつつあると思います。

そして、JSエンジンを（拙いなりに）自作できるということは自分の「推しプロポーザル」も実装出来るということです！

このトークでは、最小の実装で自分の「推しプロポーザル」であるIntl.MessageFormatの初歩的な機能が動くまでのポイントを紹介し、JSエンジンやJSの仕様・プロポーザルへ興味を持ってもらえるきっかけとすることを目指します。

フロントエンドのテスト、うまくいっていますか？重いE2EテストやVisual Regression Testの偽陽性など、やったことがある人にしかわからない落とし穴があるのがフロントエンドのテストです。このLTでは、私が現場で直面したフロントエンドのトラブルとその解決策をノンストップでお送りします。

例えばこんな話：

• Visual Regression Testの偽陽性をガッツリ減らす方法
  • placeholder画像の読み込みタイミングによるブレを軽減する自作npmパッケージもご紹介
• テストフレームワークを段階的に移行した話
• APIの仕様変更にAPIモックを確実に追従させた話
• テストコードを後回しにして失敗した話と解決策
• などなど…

単なる「あるある」では終わりません。現場で実証済みの解決策を10連発でお届けします。

株式会社WinTicketではクライアント(Web,App,Server)から送る行動ログを数百行のスプレッドシートで管理しており、閲覧のし辛さ、更新漏れが課題になっていました。
また行動ログのスキーマはクライアント側のコードで独自で定義をしており、期待する行動ログの構造と実際に送るリクエストに不整合が起きることもしばしばありました。
本セッションでは、Protocol Buffersでログスキーマを定義して自作のGo製protocプラグインを用いてログ仕様ドキュメントと型安全なクライアントコード(TypeScript)を自動生成し、ログ実装の保守性・信頼性を向上させた事例をフロントエンドエンジニアの視点で紹介します。

WebSocket通信はリアルタイム性に優れる一方で、接続状態の把握・イベント処理・再接続戦略など、状態管理が煩雑になりがちです。

特にReactアプリケーションに組み込む際は、通信状態をUI上にどう表現するか、状態をどこまで共有するか、といった設計がUXに大きく影響します。

本トークでは、接続・切断・待機・エラーといったWebSocketの状態をReactでどのように扱い、アプリケーション上で視覚的にどう反映するかを紹介します。再利用可能なコネクションの設計、ライフサイクルに応じたイベント管理、スコープに基づいた状態の共有といった観点から、実例を交えて解説します。

Motion (Framer Motion) は JavaScript や Vue, React で利用可能なアニメーションライブラリです。
Motion を使うとまるでネイティブアプリのようなアニメーションをつくることも可能です。
本セッションでは、Motion を使って心地良いアニメーションをつくる方法を紹介します。

JavaScriptのDateオブジェクトには課題が多く、特に任意のタイムゾーンと暦を指定出来ない点は課題の一つとして挙げられていました。

このような課題を解決すべく提案された新しい仕様がTemporalです。Temporalでは任意のタイムゾーンを指定できるだけでなく、グレゴリウス暦以外の暦もサポートします。一方、この「グレゴリウス暦以外をサポートする」という仕様が直近でTemporalの実装の難しさの一員となっています。

このトークでは「異なる暦をサポートすること」の根本的難しさと、Temporalがそこに対してどのような解決・割り切りを行っている（行おうとしている）のかを解説します。

トーク内容は少しマニアックですが、この題材を通じて、「複雑で必ずしも論理的・厳密でないドメインの仕様・挙動をどう決めていくか」という私達が日々立ち向かっている課題へのヒントになればと思っています。

フロントエンドの責務は広がり続けており、その中で「エラー」の扱いは重要な課題の一つです。Result型などエラーハンドリングは確立されつつありますが、そのエラーを「UIとしてどうユーザーに伝えるか」という観点での議論は、まだ十分とは言えません。

本LTでは、その問いへの一つの答えとして、アクセシビリティの観点から「良いエラーUI」を考察します。具体的なUIデザインを交えながら、エラーメッセージの文言、表示タイミング、位置など、すぐに実践できる設計のヒントを紹介します。

このLTは、エラー実装に「アクセシビリティ」という新たな評価軸をもたらします。また、実装都合ではない、サービスの品質を高めるためのUI設計に取り組むきっかけを提供します。

▼ 話すこと

• エラーUIの設計方針
• ヒントとなるWCAG達成基準の紹介

▼ 話さないこと

• ロジックや描画層でのハンドリング実装

昨年のフロントエンドカンファレンス北海道2024では「Linterからはじめるa11y」というタイトルでLTをさせていただきました。

Linterによるa11y対応の第一歩を踏み出した後、「これだけで十分なのか」「実際にユーザーが使える状態になっているか」という次の課題に直面することが多くあります。

本セッションでは、静的解析では検出できない動的な操作やフォーカス管理、実際のスクリーンリーダーでの読み上げなど、より実践的なa11yテストが求められる場面について、自動テストを活用したアプローチを紹介します。

また、既存プロダクトに段階的に自動テストを導入した際の課題や、開発チーム全体でa11y品質を維持するための運用などについても体験談を基にお話しします。

State of React 2024 アンケートで「名前は聞くが使わない」率トップだったマイナー React ビルトイン Hooksに加え、React19で追加されたhooksを開発者目線で総ざらいします。useId／useDeferredValue／useSyncExternalStore／useInsertionEffect／useImperativeHandle／useDebugValue…「いつ・なぜ・どうやって」採用する判断軸を整理し、共通ペインをユースケース別で紹介します。「お前らいつ使うねん？」から「今やろがい」になりましょう。