トーク

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では解決できなかったコードや、レガシーコードを改修する時の考え方を紹介します。

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

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

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

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

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

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

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

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

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

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

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 の「仕様書」としての未来について考察します。

Reconciliation is the action of making one view or belief compatible with another.The reconciliation process is used in various modern frontend JavaScript libraries and frameworks like React, Vue,Angular , Svelte.Reconciliation is a process of comparing the current and the previous DOMs (Documents Object Mode and applying the necessary updates on the real DOM with a minimal set of required change.

フロントエンドエンジニアのみなさん、 週末なにしてますか？

きっとコードが書きたくて書きたくて、個人開発をしているでしょう。

しかしフロントエンドだけだとWebアプリは完成しません、バックエンドやデータベースなども構築する必要があるでしょう。

我々はしがないフロントエンドエンジニア、フロントエンド以外は専門外、個人開発でAWSなどを使うのは金銭的にも厳しいのが現実。

フロントエンドエンジニアのみなさん、 Cloudflare使ってますか？

CloudflareはWorkersやPages以外にもフルスタックな開発が可能な様々なサービスをほぼ無料で利用できます。

これらのサービスをTypeScriptを使って開発できるのです。

フロントエンドエンジニアのみなさん、 フルスタックエンジニアになってもらっていいですか？

静的Webサイト生成（以下、SSG）という、テンプレートからHTMLを生成する技術があります。

SSGにはNext.jsやAstro, Gatsby.jsなどが広く用いられています。いずれもフレームワークとして様々な機能を備えている一方、プロジェクトによっては全ての機能を活かしきれず、むしろキャッチアップコストの増大に繋がる場合があります。

このトークでは、シンプルかつメンテナビリティの高いSSGの基盤をVikeで構築した際のケーススタディを紹介します。
具体的にはMeguro.es ( https://meguro.es ) のWebサイト開発におけるVikeの活用方法を通して、いかに少ない工数で壊れにくい静的Webサイトを作成したのかお話します。

モーダルとはウェブアプリケーションにおいて主要な画面の上に表示される少し小さなウィンドウです。このモーダルは現在のウェブアプリケーションの開発において(比較的)切っても切れないものになっています。

従来、Reactでモーダルを表示させるにはモーダルの開閉状態を管理していました。しかし、Nextjs13からParallel Routesが導入されモーダルの状態管理から解放されました。
本セッションではNextjsを使ったモーダルの実装例から状態管理をせずにUIを構築できることの良さについてお話ししていきたいと思います

アラカンおじさんのnakayoshix(なかよしX)こと中村良幸です。ヨーガ歴30年のダルシム系エンジニアですが、現在は隠居系フリーランスとしてデータサイエンティスト兼機械学習エンジニア的な仕事をしています。

私はフロントエンド方面に関しては全くの素人ですが、つい最近Twitter(自称X)にてPythonで作られたWebアプリ作成用ライブラリ『Gradio』の存在を知り、これは面白そうだということで早速使ってみたところ、機械学習向けWebアプリが本当に瞬殺で作れることがわかり、この興奮と感動をこの機会に是非皆さんにもお伝えしたいと思いました。

なお、Gradioで作成したWebアプリはHuggingFaceのSpacesでアプリを公開することも可能で、Stable Diffusionで有名なWeb UIの一つstable-diffusion-webuiもGradioを使用しています。

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

ここでいうユーティリティライブラリとは、例えば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を各種要件を満たしながら実務で実装した経験を踏まえ、実装するに当たっての考慮点と実装例を紹介します。

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

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

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

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

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

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

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

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

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

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