トーク

React Aria は、アクセシブルな UI コンポーネントを構築するのに役立つ Headless な React コンポーネントとフックを提供するライブラリです。コントリビューターとしての視点や React Aria を業務で使用した経験をもとに React Aria の魅力と今後の課題について5分間で紹介します。

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

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

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

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

現代におけるフロントエンド開発ではより良い体験を提供するため、様々なビルドツールを駆使するのが当たり前となっています。
しかしこれらは本当に必要なのでしょうか。「そもそもブラウザではビルド不要でJSが動くんだし、もうちょっとなんとかなってもいいんでない？」と思うことはないでしょうか。
本発表ではフロントエンドにおけるビルドの概要と必要性を検討した後、それを回避する方法を考えます。そしてビルドツールを不要とするフロントエンド開発としてDeno FreshとHotwireを取り上げ、全く異なる流れを汲む両者に共通する思想を検討します。

Reactの状態管理ライブラリ戦国時代の今，新規開発プロダクトでReduxを採用した事例について話したいと思います．
Thunk,Saga，を検討した後にRTK Queryを用いて新規プロダクトをリリースまで持っていった検討経緯について，実際のプロダクトベースでお話したいと思います．

現在、我々のサービスでは複数のプロダクトをフロントエンド・バックエンドともにTypeScriptを用いて開発しています。TypeScriptで統一されていることを活かす事で、OpenAPIやGraphQL、gRPCを採用せず、Zodのみを使用して以下の方針でスキーマ駆動開発を実現することができました。

• Zod（任意のスキーマ定義ライブラリ）を使用して、スキーマを定義する
• FE(フロントエンド)/BE(バックエンド)はそのスキーマを使用する
• FE/BEの各フレームワークに合わせてアダプターを作り、そこで型の補完やスキーマの正しさの保証（バリデーション）ができるようにする

TypeScriptにおける、コード生成を伴わない軽量なスキーマ駆動開発の第三の選択肢を提示します。

我々のサービスの中の、6年以上開発を続けているサービスのフロントエンドのプロジェクトでは、初期の頃に設定されたTSConfigがそのまま運用されています。
そのためanyやnullチェックを怠っている箇所が多く、改修や機能追加のたびにインシデントが発生していました。

そこで、suppress-ts-errorsを使用し、10万行弱のTypeScriptのTSConfigを厳しい設定に一気に変更しました。
その経験をもとに、suppress-ts-errorsでは解決できなかったコードや、レガシーコードを改修する時の考え方を紹介します。

コードレビューは単なるエラー探しではありません。それはチーム全体の成長と製品の品質を高めるための共同作業です。

『コードレビュー、時間がかかりすぎてなかなか進まない...』『レビューで指摘されることが多く、コードの品質に自信が持てない...』『ドキュメントやコメントが不足していて、コードの意図を理解するのが難しい...』こんな悩みを抱えてはいませんか？

このセッションでは弊社におけるコードレビューの効率化と品質向上のために行った取り組みについて紹介します！

最新のCSSの進化により、JavaScriptを使わなくても驚くほど多彩な表現ができるようになりました。
このトークでは、モダンCSSの機能を存分に活用して作った発表スライドを使って、CSSの可能性をご紹介します。
プレゼンテーションソフトの既成テンプレートでは実現が難しい表現も、Web技術を使えばデザインの自由度は無限大です。
本トークを通じて、モダンCSSがプレゼンテーションの表現力を大きく広げる可能性を感じていただければ幸いです。

仕事の都合で、急にFlutterエンジニアとして生まれ変わった俺。
でも前世でReactを触っていたおかげで、コードも読めて機能も実装できちゃう！？

このセッションでは、フロントエンドエンジニアの人たちに気軽にFlutterエンジニアとして転生してもらう話をしたいと思います。

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

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

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

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

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

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

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

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

バックエンドの開発は憂鬱...そんなあなたにAWS Amplify Gen2お伝えしたい。
AWS Amplify Gen2を利用すると認証、データベース、ストレージをバックエンドを意識せずにTypeScriptを用いて爆速で用意する事が可能です。

今回はコードを示しながら、バックエンドを意識しないコードファーストなWeb開発を体験して「コードファーストな考え方」に触れます。

フロントエンドの壁の一つになるバックエンドのコントロールをTypeScriptで行い、フロントエンド開発の体験向上を行いましょう！

• 行うこと
  • コードをベースに認証、データベース、ストレージを用意する方法の（高速）デモ
• 目指すこと
  • AWS Amplify Gen2を利用した爆速バックエンド構築体験
  • AWS Amplify Gen2を利用しようと試みる第一歩を後押し

昨今バックエンドの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はいいぞ！

React を使用してSPAとして Web サービスのフロントエンドを提供していますが、
node.js 16 LTS が全然ロングじゃなかった煽りをうけて、フロントエンドをビルド環境も変更を余儀なくされた方も多いはず。
弊社でもならと、以下のような変更を行いました
・ビルド時に使用しているOSのバージョンアップ(Amazon Linux 2 から Amazon Linux 2023)
・Create React App が もう非推奨になっていたため vite に変更
しかし、ローカルで開発している時は、全く問題なかったものの、プロダクションビルドしてみると画面が真っ白に、、、
あれやこれやと試行錯誤をしているうちに、原因がわかってきました
本LTではこの辺りの試行錯誤の過程を端折って、本当に大事な結論としてのviteを使ったビルド時に考慮するべき内容を、その仕様と合わせてお伝えします

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

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

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

Threlte（スレルト）は、ウェブのための3Dフレームワークです。コンポーネントフレームワーク「Svelte」と、WebGLをベースにした3Dコンピューターグラフィックライブラリ「Three.js」をもとに、Grischa Erbeらが開発しています: https://threlte.xyz/

このフレームワークでは、宣言的な形式でThree.jsにある全ての機能を利用できます。また、物理エンジンのRapierや、アニメーションライブラリTheatre.jsも統合されています。加えて、glTFを変換するツールや、VR/ARのための機能も用意されています。

本発表では、Reactの3DライブラリReact Three Fiberや、Svelte GL、Svelte Cubed、Svelthreeといったライブラリとの比較も交えて、Threlteの概要を紹介します。

The windows Subsystem for Linux(WSL) let's developers runs a GNU/Linux environment including most command -lines tools , utilities and application directly on the windows, unmodified without the overhead of a traditional virtual machine or dualboot setup.
The remote -WSL extension lets use VS code on windows to build Linux application that runs on the windows Subsystem for Linux (WSL).

JSON API が「型の割れ窓」と称されることもあるように、エンドポイント ―特に JSON ― の型付けには多くの開発者が頭を悩ませてきました。

世間にはフルスタックの風潮もある中で、技術スタックに手を加えられない環境も多々あることでしょう。
バックエンドが OpenAPI を生成するならそこから型定義も生成できますが、そうでない場合は？手書き？いやいやご冗談を。

本セッションでは、いずれの条件も満たさない「孤独」な環境に焦点を当てます。
まず、フロントエンド技術者が慣れ親しんだ TypeScript を用いて JSON API を型付けする、基本的な手法をおさらいします。
加えて、仕様としてのエラーレスポンスも型を付けて扱えるようにしたり、型定義から開発者向けのドキュメントを生成できるようにすることで、型定義の枠にとらわれない、API の「仕様書」としての未来について考察します。