トーク

React Hook Formはバリデーション機構を備えた、パフォーマンスが高く柔軟なフォームを開発するためのライブラリです。

我々のサービスでは、フォームを提供する画面にReact Hook Formを使用しています。改修を重ねて複雑になっていたフォームのコードを整理した経験をもとに、複雑さを抑えるためのフォームの設計方法や、ライブラリ標準の機能では実現できなかった課題を解決するための実装を紹介します。

具体的には、以下の内容についてお話しします。

• Contextを用いたコンポーザブルなフォーム設計
• バリデーション用スキーマを動的に "切り替える" 方法
• フォームが変わった時に、変更の差分を通知する方法

北海道内では現在フロントエンドと呼ばれる領域が十分に広まっておらず、どう取り入れるべきか、どのようにして取り組めばいいのかが適切に伝わってないような気がしています

この登壇では登壇者個人の視点でありながらも、北海道内の地場企業がフロントエンドと呼ばれる領域に自社の開発リソースを投じ、事業利益に繋げるステップバイステップのやり方を提案してみようという試みです

これを契機に北海道内企業が今の形にあった最適なフロントエンド文化を築ければと思っています

Webアプリケーション開発にはデータを取り出すバックエンド開発が不可欠です

そのバックエンド開発にはフロントエンドの領域以外の知識が要求されることが多数存在します

今回はフロントエンドエンジニアの目線に立ち、認証、データベース、ストレージ、SSRをバックエンドを意識せずにTypeScriptを用いてコードファーストなアプローチを行います。

このトークでは実際のコードと動作を確認しながらAWS Amplify Gen2を利用して「コードファーストな考え方」を理解を行います。
その結果バックエンドが苦手なエンジニアがコードでバックエンドの領域をコントロールし、フロントエンドの開発体験を向上させることを目指します。

• お話すること
  • コードをベースに認証、データベース、ストレージを用意する方法
  • TypeScriptをベースにバックエンドを用意する方法

昨今バックエンドのAPIと連携したフロントエンド開発は当たり前となってきています

そうするとバックエンドAPI開発と並行して開発が行われることがほとんどで、
開発途中でのお互いの仕様変更の取り込みをどのように行うのかという課題が出てきます

今回はその課題を解決するために、OpenAPIを中心にした開発を行い、コード生成によりインターフェースの統一を行いました
結果として、結合部分の認識齟齬を最小限にしたReactとPHPのプログラムを同時に開発を進めることが出来ました

OpenAPIを中心に据え、その周辺ツールも最大限利用することでみなさまの開発体験が向上することを目指します

• お話すること
  • OpenAPIを利用するメリット
  • OpenAPIを利用した具体的な開発手法

コストがかからないWebアプリケーション開発を行いたい、エンジニアなら誰しもが考えることだと思います

今回はフロントエンドエンジニアと相性が良い、Cloudflare PagesとCloudflare Workersを中心に据えて、
TiDB ServerlessとMomentoを利用したコストメリットが高いWebアプリケーション開発を考えます

無料枠存分に利用しながら開発を進める事で、Webアプリケーションを世の中に気軽に公開しましょう

無料枠で収まらなくなった...？その時はあなたのアプリケーションがマネタイズを考えるときです
コストメリットの高いアプリケーションを用いて世の中を支えながらマネタイズを検討しましょう

• お話すること
  • Cloudflare、TiDB Serverless、Momentoの利用方法
  • TypeScriptをベースとした開発手法

コードリファクタリングをしたい...！エンジニアなら誰しもが通る道だと考えます

今回はSvelteのコードを題材に、テストを利用して安全にコードリファクタリングする手法を考察します

基本になるテストピラミッドを振り返りながら、
開発を進める中でどうしても辛くなってしまう、辛くなってしまったコードを救う方法を考えます
また具体的な手法を提示することで、みなさまのコードリファクタリングライフに一助になることも目指します

テストを利用して安全にコードリファクタリングを行って、自分たちのWebアプリケーションを守りましょう

• お話すること
  • Unitテスト、Integrationテスト、E2Eテストの概要とアプローチ方法
  • テストを利用したコードリファクタリング手法
  • Svelteはいいぞ！

古くはSASS等のプリプロセッサ系言語から、CSSモジュール、CSS in JS、ゼロランタイムへの希求など、CSSを扱う手法は注目を集めてきました。
昨今ではlayerやnestingの導入に代表されるように、CSS自体の機能も充実しつつあります。

ところで、CSSでのレイアウトを実装するとき、どれくらい仕様にある概念を意識しているでしょうか？
基本のボックスモデルはいいですよね。マージンの相殺、重ね合わせ順といった頻出問題ではどうですか。レイアウトは何の指定によって動作を変えるのでしょうか。
なんとなくうろ覚えのプロパティを書いて、ホットリロードの結果を見ながら試行錯誤する時間とはおさらばしましょう。

論理的にCSSでのレイアウトを構築する力をつけるための知識、困ったときに検索できる知識をつけて、道具選びではごまかせないモダン以前のCSS力を確かなものにするためのトークです。

フロントエンド刷新に React Aria を導入し、製品全体の性能向上への取り組みについてお話しします。

多様なブラウザやデバイス、キーボードでの操作にスクリーンリーダーによる読み上げなど、コンポーネントを実装する上で注意すべき点は数多くあります。
React Aria は、これらの要件を包括的にサポートしており、アクセシブルな UI コンポーネントの構築に適しています。

本発表では、React Aria を活用した多言語対応の DatePicker、キーボードやスクリーンリーダーで操作可能なドラッグアンドドロップ機能付きのコンボボックスなどの具体例を通じて、
カスタマイズの容易性、学習コストと実装効率など、実践から得た知見を共有します。

デザインシステムは、一貫性のあるユーザー体験を提供し、製品開発の効率を向上させるために、デザインの原則や再利用可能なコンポーネントをまとめたものです。

このセッションでは、弊社で取り組んでいるデザインシステムの構築を支えるデザインツールやプロジェクト構成、コーディングとデザインの連携方法について紹介します

iframeは、sandbox属性を利用することで、Webアプリケーション本体と切り離された安全なスクリプト実行環境として利用することができます。

しかしながら、iframeをsandbox化すると、Webアプリケーション本体からiframe内への処理呼び出しや、その逆の呼び出しが直接行えなくなります。

具体的には、それぞれのWindowオブジェクトのpostMessageメソッドと、onmessageハンドラーを利用したメッセージングを行う必要があります。この処理の実装は、目的を最低限満たすだけでもかなり重厚になってしまいます。

Comlinkは、この複雑化しやすいメッセージング処理の実装を単純化してくれるライブラリです。

本発表では、実際に発表者が開発で対面したiframe間通信実装の複雑性による課題と、それをComlinkの導入によっていかに解決したかについて解説します。

BtoB向けサービスのフロントエンドアプリケーションを開発・運営にあたっては、扱うデータの量が時間とともに変化していくため、パフォーマンス最適化は避けて通れない課題となっていきます。
また規模の大きい企業様にご利用いただく場面では、エンタープライズ向けブラウザへも観点を向ける機会が出てまいります。
本レギュラートークでは、私が所属するログラスにおいて、直近数年間のサービス運用を通じて得た気付きや実践的知見をもとに、以下のテーマでお話してまいります。

• データ量の多さと向き合うパフォーマンス向上策: 仮想スクロールなどをはじめ、取り組んだ技術的詳細について紹介
• 知られざるエンタープライズ向けブラウザの存在: Chrome Enterpriseは通常のWebブラウザとなにが異なるのかを紹介します

プログラミングにおいては、実装ミスや外部入力の誤りなど、さまざまなエラーが避けられません。
これらのエラーが適切に処理されない場合、アプリケーションの整合性や信頼性が低下してしまいます。
また、エラーの表現形式やハンドリング方法によっては、コードの責務が不明瞭になることもあります。

本セッションでは、エラーをどのように表現しハンドリングすれば、コードの責務を効果的に明確化できるのかをTypeScriptの実践例を交えて紹介します。

本セッションではフロントエンドをより頑健な実装にしていくための関数型プログラミングのエッセンスについてお話しします。
フロントエンド開発においても「イミュータブル」など関数型プログラミングに関連する概念に出会う機会は多いと思いますが、いざ体系的に学ぼうとすると数学的な定義の難しさや手続き型のコーディングとのメンタルモデルの違いが立ちはだかります。
そこで本セッションでは関数型プログラミングというパラダイムそのものの基本的な考え方やフロントエンド開発に特に有効と思われるエッセンスを実装例と共にご紹介し、フロントエンドエンジニアの目線から関数型プログラミングを紐解きます。

自社や個人で開発しているサービスをスマートフォンで使えるようにする方法はいくつか存在する。

スマホのブラウザで使えるようにレスポンシブデザインに対応することや、PWAであればWebフロントエンジニアが得意な方法だろう。
また、アプリを最近話題のFlutterなどのクロスプラットフォームでアプリを開発したり、もしくはそれぞれのネイティブアプリを開発する選択肢もあるだろう。

どのような選択肢が存在するのか、それぞれのメリットデメリットを考え、どのような場合にはどの選択肢がベターなのかをネイティブアプリ開発者の視点からお話しします。

現代のフロントエンドは様々な技術によって支えられています。ライブラリを使えば解決する課題が多くある時代です。

しかしながら、100%自分たちの解決したい課題にマッチするとは限りません。最後の最後は己の力で帳尻を合わせていく必要があります。

本発表で扱う題材はファイルツリーです。エディタを利用している人であれば1度は見たことあるUIです。様々な仕様が存在し、さまざまな責務との境界に面している場所のひとつです。

基本的なデザインパターンや、アルゴリズムを用いて実装することはもちろん、リアルタイム通信やユーザーインタラクションが発生した場合、どのように実装するのか、一緒に考えていく発表をしたいと思います。

本発表の対象者はJavaScriptを知っている人なら誰でも聞ける内容を予定しています。

GraphQLは非常に強力な技術で、うまく使えばWebフロントエンドだけでなく全体の開発体験やユーザ体験を大きく向上させてくれます。
一方で、使い方を誤るとユーザ体験は悪化し、バックエンドやインフラのエンジニアを苦しめ、フロントエンドにまで生産性低下や将来の負債を生み出すこともあり、使えばそれでOKという技術ではありません。

では、ユーザも関係する全ての開発者も、誰もが消耗せずGraphQLの恩恵を享受するには？
それには実装時の細かなTipsからクエリやコンポーネントの設計, スキーマ設計, アーキテクチャ, プロダクトの構成など、様々なレイヤ・抽象度のものが関係します。

本セッションでは関係者みんなが「GraphQLを入れて良かった」と思えるために、Webフロントエンドエンジニアは何を考え・どのような設計・実装をすべきかを具体的なプラクティスとともに紹介します。

「WebアプリはWebスタックでつくり、アプリはSwiftやKotlinでつくるのが正しい」という考えは根強く、多くの現場でWebフロントエンドとモバイルアプリは別物として取り扱われます。しかしユーザにとっては違います。Google検索でアプリを探すように、アプリストアから自分にあうアプリを探します。気に入ったWebアプリはモバイルアプリで使いたくなったり。

本セッションでは、Webアプリの時はユーザが少なかったアプリが、モバイルアプリをリリースすると多くのユーザを獲得した実例から、プラットフォームの特性やユーザ行動の違い、そしてWebアプリをモバイルアプリ化できるCapacitorの簡単な始め方と、モバイルアプリだからこそできる機能拡張についてお話します。

Webフロントエンドからモバイルアプリ領域に手を広げることで、ユーザに選択肢を、アプリにより大きな価値をつくりましょう！

プロダクトを長期運用していると、定期的なマイグレーションの必要性が生まれます。「フレームワークの記法が変わった」「ECMAScriptにプライベートプロパティが導入された」等、誰しも「本当にこれ手作業で書き換えするの？生産性とは！！！」という経験をしたことがあると思います。

様々なマイグレーションを試みましたが、フロントエンドにおいてはESLintの自作ルールは最強のマイグレーションツールになりえます。本セッションでは実際に公開している @rdlabo/eslint-plugin-rules を例に、ルールとマイグレーションの自作を推奨し、簡単な始め方のご紹介をします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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