トーク

私のフロントエンドエンジニアとしての経験を踏まえて、プロダクションに積極的に導入したいユーティリティライブラリの選定例と実装例をご紹介します。

ここでいうユーティリティライブラリとは、例えばZod(JavaScript、TypeScriptでスキーマバリデーションを表現できる人気のライブラリ)等のコーディングを補助してくれるライブラリです。

各種ユーティリティライブラリの導入はフロントエンドのアーキテクトにおいて、1つの論点となっています。しかしながら、プロジェクト全体でどのようにユーティリティライブラリを活用していくべきなのか・選定するときの観点は何を重視して判断すべきかの知見は、コミュニティには広まっていないと感じています。

このようなユーティリティライブラリの選定の思考を踏まえつつ、zodと共にts-patternというパターンマッチライブラリの導入例を紹介したいと思います。

例えばSHEIN ( https://m.shein.com/jp/?lang=jp )のWebサイト等に実装されているカテゴリ選択するメニューのようなUIを実装したいと思ったことはありませんか？

iOS/Android等でスタックナビゲーションとよばれるこのUIはSP重視のtoC向けのプロダクトではデザイナーからも人気の高いUIです。
しかしながら、スタックナビゲーションのUIの実装例はコミュニティにほとんどなく、SEOやアクセシビリティ、コンポーネントのメンテナビリティなどの要件を満たしながらWebで実装するのはかなり難しいUIになります。

このようなスタックナビゲーションのUIを各種要件を満たしながら実務で実装した経験を踏まえ、実装するに当たっての考慮点と実装例を紹介します。

フロントエンドにおけるコンポーネント設計の目的と設計方針を整理しながら、私の考えるコンポーネント設計方針(コーディングスタイル)とその意図を丁寧にご紹介させて頂こうと思います。

フロントエンドエンジニアとして業務に携わり始めた5年前からコロケーションの概念を中心にコンポーネント設計方針を自分なりに考え実務で適用してきました。

多くのフロントエンドにおけるプロジェクト・コンポーネント設計論が既にコミュニティで多く共有されていますが、実務に適用するには過剰・不足している点が多いと思います。特によくあるミスマッチは「プロジェクトの規模感に合わない」だと考えています。

私の考えるコンポーネント設計論では、コードベースの拡大を念頭に置きつつも、その時々のコードベースに対して常に最適に変更していける点を意識しています。
このような特徴を持つ私のオレオレコンポーネント設計論を共有します。

現代の多くの Web サイトにとって、Core Web Vitatls のような User-centric なメトリクスは非常に重要です。

Lighthouse などのツールは、計測環境を固定して使用すれば、変化の激しい Web サイトに対しての有効な定点観測手法となりますが、一方で実際のユーザー体験とは乖離することもあります。
New Relic などのオブザーバビリティバックエンドにある RUM（Real User Monitoring）機能では、エンドユーザー端末での実測をするため、ユーザー層や固有のコンテンツに依存したより現実的なデータが得られますが、一方で変数が多すぎるため、ある変更がパフォーマンスに与えた影響を把握するのには向いていません。

本トークでは、実際の Web サイトでこれらのラボデータ・フィールドデータをどのように活用して CWV を改善していくべきか話します。

ブラウザによる「テキスト描画」について、Chromiumへのコントリビュートを通じて得た知見をもとに深ぼります。

ブラウザが受け取ったデータはシェイピングエンジンやグラフィックライブラリなど、様々なモジュールを通って初めてモニター上のピクセルとして具現化されます。

ただし、多くの要素が事態を複雑にします。

フォントの変更。CSSによる線や強調点、カゲの付与。
カーソルにより選択された部分のハイライト。

縦書きもあります。アルファベットは時計回りにまわしましょうか。

……アルファベットとひらがなが混ざった縦書きもあるのか。

えっ、隣に来る文字に依って形が変わる文字がある？

そういえばカゲって、強調点のカゲも描画しないといけないんでしたっけ？

えっ、打ち消し線のカゲがテキスト本体より前に来てしまうバグ？

……さて、ブラウザはどのようにしてテキストを描画しているのでしょうか。

2023年9月、Svelte開発者Rich Harris氏からSvelte5とRunesが発表されました。1
2024年4月、同じくRich Harris氏がSvelte5のRCを発表しました。2

Runesとは一体何者なんでしょうか。
Svelte4とSvelte5ではなにが変わるのでしょうか。

本発表では、Svelte5およびRunesを簡単に紹介します。

発表者はサーバーサイドの開発に強みを持っていますが、必要に応じてフロントエンドやインフラの開発も行う業務プログラマです。
業務でのフロントエンド開発としては、これまでReact、React Native、Vue.js、Flutter(ネイティブアプリ)などのモダンなライブラリ・フレームワークも利用しています。

発表者は、デザイン、formatterやlinterやビルドなどのフロントエンドツール設定、ネイティブアプリの設定などについて短時間で行えるほど習熟していません。
そういった状況でも一人で行なっている趣味の開発でフロントエンドが必要な場合にFlutter on the Webを用いると大きな時間をかけずに満足いく表現を行えました。

今回はその経験を通じて、似たような境遇の人にFlutter on the Webを選択肢の一つとして紹介します。

本LTではバックエンドエンジニアから見たフロントエンドとの分割における「つらみ」を「状態管理」の視点から明らかにし、軽減するためのアイディアを紹介します。

• 状態の2重管理
• なぜ2重管理になってしまうか
• 対策案

バックエンドのAPIとして、Java/Go/Ruby/PHPなどの処理を呼び、フロントエンドはUI/UXに注力するというアーキテクチャは現在よく取られている手法です。
明確な境界があることで責務は分断され、業務ロジックはバックエンドに秘匿され、多くのメリットが享受できます。

一方でステート（状態）はどうでしょうか？
ユーザーの利便性やわかりやすさのためにフロントエンド側で一時的な状態を保持し、画面を組み換え、POSTします。
フロントエンド側で更新された状態を改めてバックエンド側でチェックし、永続化することが多く、状態の保持に関しては複雑性が増してしまいます。

Nuxt では個々のコンポーネントをサーバーサイドでレンダリングすることができる Nuxt Server Components を提供しています。

このセッションでは Nuxt Server Components が解決する課題、具体的なユースケース、React Server Components や Astro Islands との違いについてお話しします。

このセッションを通じて Nuxt Server Components の機能と利点を理解し、自身のプロジェクトにどのように適用できるかを知ることができます。

最近、ぼくはメガベンチャーのプロダクトデザイナー（兼フロントエンドエンジニア）から、
０->1な事業開発を推進するキャリアへ舵を切りましたが、開発に対しての考え方も変わりつつあります。

画面設計、UIコンポーネントの選定はもちろん、品質への考え方、開発スピード、プロジェクトの進め方など...
それらへの思考は、事業ドメインや、事業成長のフェーズによって大きく変化します。

ただ、どのフェーズでも営利活動において、モノづくりをする理由はただ一つ共通しているはずです。
それは「事業・ビジネスに貢献する」ことです。

本トークでは「事業におけるフロントエンドのあり方と考え方」をお話ししようと思います。

趣味サイトくらい
新しく技術を試したいじゃないか

こんなプロトコルでデプロイしよう
HTML のこの要素を試してみよう
CSS はこんなふうに書いたら楽しいな
JS はあの機能が気になってたんだ

そんな夢のような個人サイトを作った話

202X 年になればみんな見れるかな
見れるといいな
ちょっと先取りしすぎたかな

あなたはこのサイト
表示できますか？

事業上の要請で、Webアプリとして提供しているサービスでプッシュ通知等のネイティブ特有機能が必要になり、モバイルアプリ版を新たに出すことはよくあると思います。その場合、フルスクラッチで開発するとめちゃくちゃ大変です。まずは最小限の工数で通知許可率等を計測し、モバイルアプリのポテンシャルを検証したいですよね。

本セッションでは、Capacitorを用いて既存のNext.jsアプリをそのままモバイルアプリとして動かし、プッシュ通知のようなネイティブの機能を利用するまでをステップ・バイ・ステップで解説します。また、このアプローチで700万MAUのサービスを3年間運用した経験を元に、単一のコードベースでWebフロントエンドとモバイルアプリを運用する上でのTipsも紹介します。

Web開発者が事業を前進させる現実的な選択肢としてモバイルアプリ開発を検討するきっかけになれば幸いです。

Viteがいま流行っています。
React系ではRemixが、Vue.js系ではNuxtが、Svelte系ではSvelteKitが、、、Viteを利用しフレームワークを構築しています。

この背景には、esbuildを利用した速さや、ESModulesを活用した開発環境など開発体験に基づく理由も大きいでしょう。
ですが、これ以外にも優れたインターフェイスを備えたプラグインシステムが大きな理由の１つになっていると考えています。

本発表では、Viteとその元になったRollupのプラグインシステムおよび、その優れたインターフェイスを確認し、Viteの優位性を確かめます。

昨今Rust製のツールチェインが流行り、ESLintの代わりにBiomeやOxc(oxlint)を採用するケースも増えているのではないでしょうか。
ですが、これらは未だ独自のカスタムルールを利用することはできません。

対するESLintでは、非常に優れた拡張性を持っています。
中でも no-restricted-syntax というプリセットのルールは、簡単に独自のカスタムルールを作成することが可能です。

本発表では、 no-restricted-syntax を利用した実用的なカスタムルールを作りながら、ESLintの有用性を再確認します。

ブログなどのコンテンツを投稿できるWebサービスを開発する際、コンテンツを編集するためにエディターを開発することがあります。tiptapは、WYSIWYGエディターを開発するためのツールキットです。

このトークでは、Tiptapを使ってエディターの機能を開発する方法と、より高度なAPIであるNode viewsやProseMirror Pluginsを使ってオリジナリティのある機能を開発する方法について話します。

対象者
・ tiptapによるエディター開発の初心者・中級者

フロントエンドで発生したエラーのトラッキングをしたいと思った時、Sentryのようなツールを導入することで解決しようとしている組織は少なくないのではないかと思います。

しかし、エラー監視はどれだけいいツールを使っていたとしても、実際に運用していく体制がずさんではあまり効果を発揮することができないと考えています。

そこで、わたしたちは「cop当番制度」というものを導入することで、エラー監視の負荷が特定のメンバーに集中するといった問題を発生させることなく、レポートされたエラーをしっかりトリアージしきることを実現しています。

本LTではどのようにしてフロントエンドのエラー監視体制を運用しているのか、技術面ではなく運用面にフォーカスしてお話しします。

1つのNext.jsアプリケーション用として運用していたリポジトリをモノレポへ移行した話をします。

プロジェクトごとにリポジトリを分けるポリレポに対して、モノレポでは「プロジェクト間でコードの共通化がしやすい」「プロジェクト間の依存関係が見やすい」といったメリットがあります。
しかし目的の異なるコードベースを1箇所にまとめるためメリットの反面、複雑さが増す部分もあり、例えばCI/CDが遅くなる・余分に実行されるなどの問題が発生しました。

このセッションでは、実際にモノレポへ移行した流れと発生した問題、その解決策をお話しします。

お話しする予定の内容

• pnpm workspaceを使ったモノレポの始め方
• dependenciesの管理方法
• モノレポツールの必要性
• GitHub Actions, Dockerfileの最適化

エッジコンピューティングが急速に普及する中で、フロントエンドとバックエンドの従来の境界がどのように変化しているのか、そしてエッジをどちらのカテゴリに分類するかは面白いトピックです。
このセッションでは、エッジがフロントエンドとバックエンドのいずれに属するのか、またはそもそもこのような区分けが適切かどうかを探ります。技術的な境界がどのように変化しているかを見つめ直し、エッジが伝統的なカテゴリにどのように収まるのかを検討します。

僕はよく、ソフトウェアから独立したテストを用意します。クライアントサイドのテストを書く時はブラウザテストを書き、サーバーサイドのテストを書く時は fetch もしくは cURL でエンドポイントを叩きます。データベースにテストデータを挿入する際もORMなどを使わずにSQLドライバーそのものを使います。つまり、対象となるソフトウェアについて無知な前提でテストを用意します。

このやり方はライブラリのテスト支援機能を使えないので開発速度は落ちますが、テンプレートを作れば十分にカバーできます。そして何よりも、将来別のライブラリや言語に移行するときに、テストケースをそのまま使いまわせるという利点が生まれます。つまりテストが生きた仕様としてソフトウェアから独立してくれます。

このようにソフトウェアから独立したテストケースを作るテクニックやモチベーションについて、このトークでは話します。

Redux Toolkitは、ステート管理ライブラリであるReduxをより使いこなし、効率的にアプリ開発をするためのライブラリです。

我々のサービスでは、複雑なフォームを提供する画面にReact、ReduxおよびRedux Toolkitを使用していました。
ある時、Redux Toolkitのマイナーバージョンアップを行うと、フォーム入力時の再レンダリングにかかる時間が約4倍になってしまいました。
もちろん、バージョンアップ以外に実装は何も変わっていません。

普通はマイナーバージョンアップでそんな劇的な変化は起こらないはずです。皆さんは、マイナーバージョンアップで何が起こったのか想像できますか？