トーク

コードベースに秩序をもたらすため各種 Linter を利用している方も多いのではないでしょうか？一般的なルールについては Linter 内蔵のものや既存の Plugin ですでにカバーできるでしょうが, 一方で事業ドメイン特化であったり UX/DX を向上させるための技術ドメイン特化なルールまではサポートし切れないケースの方が多いでしょう.

日経電子版においてもコードベースにそうした事業ドメイン, 技術ドメイン特化な制約が存在しています. こうした日経電子版特化な制約について日経電子版開発では属人的なレビューで弾くといったアプローチでなく, できるものは ESLint Plugin を開発してそれにより機械的に弾くアプローチをとっています.

本セッションでは事業, 技術ドメイン特化な ESLint Plugin を開発する利点や How To を具体例とともにご紹介します.

Web アプリケーションを開発する中で, 同一アプリケーション内の他ページや別アプリケーションへのリンクを纏めた Global Navigation をヘッダーやフッター部分などに横断的に配置したくなるケースがあるでしょう. 事業の成長に伴って Global Navigation の内容も進化していくものですが, 一方でアプリケーションのリポジトリやサービスが分散されているとその更新やデプロイコストが高くなってしまいます.

日経電子版においてその更新コストに Platform Engineering でどのようにして立ち向かってきたか, そしてチームを跨いで利用される Platform Service の管理やコミュニケーションをどのようにして行なってきたか, を紹介し Web Frontend における Platform Engineering を行なっていくための知見をご紹介します.

React コンポーネントライブラリ Mantine をプロダクトで使うにあたり、どんな課題に直面しどう解決を図ったかについてお話します。
例えば以下のような課題です。

• デザイン上のフォントサイズ粒度と Mantine で設定可能な粒度が異なる
• 様々なスタイリング方法が提供されており、柔軟な反面、実装においては複数の方法が混在することを避けたい

Mantine との向き合い方の一例をお話し、UI コンポーネントライブラリを利用した開発の参考になれば幸いです。

関連する複数のアプリやパッケージをまとめて管理するため、ポリレポではなくモノレポにすることがあると思います。
この LT では、初めてモノレポを構築した自分の経験談を話します。
例えば、

• モノレポ構成を取るにあたり、どういった観点で何を検討したか
• 検討事項に対して、どういった決定をしたか
• モノレポを構築するにあたりどんなことをしたか

などについて話し、モノレポ構築において参考になる情報を少しでも提供できれば幸いです。

Remix を使ったアプリケーションにおけるコンポーネントの単体テストでは、 @remix-run/testing パッケージで提供されているスタブを利用すると思います。
しかしこのスタブは useRouteLoaderData を利用しているコンポーネントではうまく動きません。
このように、 Remix 公式から提供されているスタブではカバーできることとできないことがあり、公式ドキュメントには特に記載がありません。
この LT では、

• RemixStub がカバーしていることとしていないこと
• useRouteLoaderData hook を使っているコンポーネントの単体テストをどうやるか
• remix-typedjson を使っている場合に発生する別の課題とその解決方法

などについて話し、Remix を使った開発を行っている方々の助けとなる情報を届けられれば幸いに思います。

チームで開発をしていると、こういうコンポーネントが存在してるかを確認するためにStorybookを見る、どういうAPIが生えているのか確認するためにSwaggerを見るということを頻繁に行うと思います。
その際にいちいちnpm run storybookなど別プロセスで実行して確認するのも実際少し手間ではありますし、devブランチに入っている最新版のAPIを確認しようにもgit pullしないとかぁ…という状況もしばしば。
むしろgit pullのせいでコンフリクトが発生してstorybookが気づかずにエラーで止まっちゃってたということも…
エンジニア以外にも簡単にコンポーネント一覧見てもらうには…などなど。

そこでVercelを活用することによってチームに所属している人間のみが簡単にブラウザ上で見れるような環境を用意できる、そういう方法を発表したいと思います。

shadcn/uiはRadix UIをベースとしたUIコンポーネントライブラリです。コピペして使えることで有名ですが、実際にコンポーネントの中身を見ていくとコンポーネントを設計する上での気付きや発見があります。

そんな気付きや発見を紹介するLTです。

発表内容

• cvaを使った関心の分離
• プリミティブではないコンポーネントがどういう設計になっているかみる（Formコンポーネント）
• コンポーネントがどう振る舞っているか

ChatGPTの発表以来、生成AIを活用したサービスが数多く登場しています。これらのサービスにおいて、生成AIとユーザーをつなぐ重要な役割を担っているのはフロントエンドを担当する私たちです。
私の取り組んだ「わたしの現代新書」も生成AIを取り入れたプロジェクトです。このサービスでは、ユーザーが入力した書籍のタイトルをもとにAIがキャッチコピーを生成し、vercel/ogを使って書影画像をつくります。
この企画を作るにあたって、生成AIを利用する際にユーザーが待ち時間を感じないようにするデザインの工夫と、素早く高品質な画像を生成するエンジニアリングの工夫を行っています。その結果、多くのXユーザーに利用されるものになりました。
本セッションでは、デザインとエンジニアリングをどのように組み合わせたか、具体的な取り組み内容について詳しくお話しします。

昨今、街歩きがブームとなり、歴史的な地図への関心が高まっています。
「れきちず」は昔の歴史地図を現代風のデザインにアレンジし、誰もが使いやすく読みやすい地図へと進化させました。
「れきちず」は見た目だけでなく技術面、フレームワーク・地図タイル・3D地形・データ変換のパイプライン…などなどがフロントエンド技術を中心としたユニークな技術スタックで構築されています。
このセッションでは「れきちず」のオモテ側のデザインを紹介しつつ、ウラ側の技術についても深堀します。

この発表では、サイボウズが提供する製品「サイボウズ Office」における、フロントエンド (Next.js App Router) の監視基盤について紹介します。

React Server Components や Server Actions のようなサーバーの存在が前提となっている機能の登場によって、フロントエンドにおいてもサーバーを運用する必要性が高まってきました。このセッションをきっかけとして、フロントエンドの監視に関する知見が広がることを目指します。

詳細は以下の内容を予定しています:

• フロントエンドサーバーにおけるオブザーバビリティデータの収集方法
• Next.js での OpenTelemetry 対応の詳細とユーザー側ですべきこと
• Grafana Faro を利用した Real User Monitoring の実践

本発表ではレガシーなフロントエンド開発の経験しかないチームが、デザインシステムとコンポーネント指向を導入し、従来の開発プロセスをどのように革新したかを、実例を交えて紹介します

このチームはレガシーなコードの肥大化と複雑化に伴い、メンテナンス性と拡張性の問題に直面していました
新たなサービス開発を機にアトミックデザインをベースにしたデザインシステムの導入と、SPAフレームワークを用いたコンポーネント指向開発に挑戦しました

コンポーネント指向はUI の再利用性と組み合わせ性が向上させ、サービスを高品質に、なおかつ柔軟性をもたらしました
さらにデザインシステムの導入はチーム内のコミュニケーションと協業にも好影響を与えました
共通言語はデザイナーと開発者の連携がスムーズに変化させました

本発表を通して、コンポーネント指向に立ち向かう具体的なイメージを持っていただけると幸いです

大規模なBtoBサービスにおける段階的なシステムリプレイスを実施しています。JSPで構築されているシステムのフロントエンド部分をNext.js（Pages Router）とGraphQL（Relay）にリプレイスしています。
フロントエンドチームのリーダーとして関わり、開発を開始してから約2年が経過し、初期リリースからは約1年が経過しました。
これまでの経験から、リプレイスを進める中で良かったこと、大変だったこと、技術選定の振り返り、今後気をつけたいことなど、これからフロントエンドリプレイスを検討している方々に様々な知見を共有したいと考えています。

本セッションでは、スキーマ駆動開発に焦点を当て、その中でもConnectを利用した開発について話します。

このセッションでは、まず、スキーマ駆動開発でのIDLであるOpenAPI、Protocol Buffers、GraphQLの中で、Protocol Buffersが記述のシンプルさと柔軟性において優れている点をお伝えします。
次に、Connect-Webを活用したスキーマ駆動開発の方法について解説します。Connectは2022年に公開された、 gRPCやgRPC と互換を持ったHTTP APIを作成するためのライブラリです。 Protocol Buffersを活用したAPIの定義から、クライアント側のコード生成をシームレスにサポートします。Connect-Webの特徴や利点について詳しく説明し、実際にどのように活用するかを示します。

クリーンアーキテクチャのWebフロントエンドへの適用は、クラスとの相性やフレームワークが前提とする処理の流れと違うといった課題があり、そのままの適用が難しいことはこの数年で徐々に認識されてきたことと思います。しかし、クリーンアーキテクチャを1つのアーキテクチャとして捉えるのではなく、いくつかの設計のパターンとして捉えることでフロントエンドにも活用できる学びがあると考えています。

本セッションでは、Vue.jsでクリーンアーキテクチャの導入を試し、その後のReactへの移行に際して、良い設計を部分的に適用する中で得られた知見について紹介します。

• なぜフロントエンドにクリーンアーキテクチャは不向きか？
• types, reducers, utils を使ったエンティティの表現
• 外部インターフェイスを抽象化していたことで、Vue.js→React移行がスムーズに

ウェブフロントエンドでサイズの大きいPDFを表示しようとしてパフォーマンスやユーザビリティに悩んだことはないでしょうか？
本セッションではサイズの大きいPDFを可能な限り高速にブラウザ上で表示するための工夫と、フロントエンドでcanvasにPDFをレンダリングする方法と比べたときの実際のパフォーマンス差についてお話させていただきます。
ちなみに今回ご紹介するPDFの高速表示方法は特許を取得済みです！
https://prtimes.jp/main/html/rd/p/000000038.000063428.html

プロダクトと組織の成長に伴って複雑化していくコードベースやお客様からのご要望に「Feature Flag」という武器で立ち向かいます。
UIだけでなくバックエンドAPIとのつなぎ込みやTesting（VRTやE2E）とのインテグレーションなど、Feature Flagの活用方法は多岐にわたります。
この一年間Feature Flagと向き合い続け、酸いも甘いも（？）理解した僕が、Feature Flagを使った開発が変化に柔軟で価値検証速度を高めることができる理由とFeature Flagを使う際の注意点をお話させていただきます。

概要:
アプリケーションの構築にComponent-Drivenなアプローチがあります。このアプローチでは、コンポーネントを中心とした設計がデザインと開発の両面で重要です。しかし、デザインとフロントエンド開発の間にはしばしばコミュニケーションの断絶が見られ、結果としてコンポーネント設計において不一致が発生します。
このセッションを通じて、デザイナーとフロントエンド開発者がより効率的に協力し、一貫性のあるユーザー体験を創出できるようになることを目指します。

内容:
・ Figmaの進化： DevMode、Code Connect、フロントエンド開発者も知っておきたい内容を抜粋
・ Storybookの利用: テスト、ドキュメント、FIgmaとの連携など、Storybookの利用方法を実際の取り組みを交えつつ紹介
・ HTML,CSSの変化： コンポーネントにフォーカスした技術の変化を紹介

Next.jsのApp Routerでは、React Server Components（以下RSC)を活用した実装になっています。
RSCのServer Componentsは、名前の通りサーバー側でレンダリングされるコンポーネントです。
ここで既存のSSRも似たことをする技術ですが、RSCとの関係性・違いはどのようなものでしょうか？
本トークでは、SSR・RSCの生成物を確認しながら機能・仕組みの違いを調査します。

仕組みの違い：https://qiita.com/karintou8710/items/28dee39c5cb82bd1775d

Vue2の時代には、Reactと並んで、大人気なフロントエンドフレームワークであったいわゆるVue系。Nuxt3はリリースが遅れてしまったことに加え、大規模かつ多数の仕様変更があったこと、そしてインフルエンサー層がこぞってNextに鞍替えしてしまったことなどから、そのユーザー数は大きく減ってしまった。特に、難度が上がった仕様変更の一つとして、Fetcherの使用方法が挙げられる。

Nuxt2まではaxiosを用い、ラッパーとしてasyncDataを用いれば概ねヨシ！といった形であったが、Nuxt3からはuseFetch. useAsyncData + $fetch, useLazyFetch, useLazyAsyncDataなどを使い分ける必要性が出てきた。フレームワークへの依存性を減らしつつ、利便性があり、SSRでも活用できる、そんな理想のFetcherを求める戦いが今ここに始まる。

一時はバズワードにもなったメタバース。バーチャル世界で活用される主たる技術はUnity, Unreal、Vket Cloud、OSSのGodotなどに代表されるゲーム開発エンジンであったり、複数エンドポイント間の高速通信を可能とするRTC(Real Time Communication)技術であり、それらを支えるバックエンドやインフラである。しかしながら、フロントエンド技術が不要であるという話ではない。メタバースまでの導線として、PRの一環として、あるいはWeb VRの世界であれば、ゲームエンジンとWeb APIとのインターフェースとして、フロントエンド技術は多分に活用されているのだ。

本トークでは、VR法人HIKKYにおける、フロントエンド技術の活用例やアーキテクチャ例を紹介するとともに、一般的なWebサービスとの差異、そしてバーチャル世界におけるフロントエンドのこれからを解説する。