※ この記事は Cybozu Frontend Advent Calendar 2023 の 10 日目の記事です。 私が所属するReactoneチームでは、React + TypeScriptを用いてkintoneのフロントエンド刷新を行なっています。 内定者アルバイトとしてReactoneに配属された当初、私は抽象化された見慣れないモジュールの数々の読解に時間がかかってしまいました。 しかし、そうした抽象化は「デザインパターン」と深く関係しており、Reactoneのコードベースでは、大規模プロダクトのフロントエンド刷新において保守・運用性や再利用性の向上に寄与する重要な要素の一つとして、デザインパターンが適切に組み込まれたり改良されたりしていることがわかってきました。 今回は、学生ももう終わり（？）ということで、ハッカソンで「とりあえず動けばヨシ！」みたいになっていた頃の自分に一石を投

はじめに ニコニコ生放送でフロントエンドを担当している misuken です。 今回は関心が分散してしまう理由やその原理、この問題に対する適切な対処法を通して、package by feature の合理性や、そこで重要になってくる関心の単位などについて解説していきます。 規模の大きなものを扱っている方、分類が苦手な方、分類に関して悩みを感じている方には特に有用です。 前提 Reactでコンポーネントを管理する例で説明します 当然React以外の様々なディレクトリ構成でも応用できます BCD Design の概念も覚えておくとより体系的に理解できます 精度の高い明名ができれば、分類の効率も精度も上がります 現実世界で捉える関心の分散 通常、自宅や職場でトイレに行くとき、同じフロアや同じ建物内のトイレに行きます。 もしもトイレだけの建物が隣に建っていて、そこに行かなければならないとなったらと

Next.jsの対抗馬となりそうなReactのフレームワークでRemixのv1.0がリリースされました。 個人的にRemixでいちばん魅力を感じているのはCloudflare WorkersでSSRができるという点です（現状ではNext.jsをCloudflare Workers上でSSRするのは難しい）。これがなぜ嬉しいのかと言うと、パフォーマンスを出しつつ、低コストで運用でき、大量のアクセスに対しても低コストでスケールできそうだからです。 そもそもSSRをする必要ある？ ほとんどのWebサービスはSSRなしでSPAとしてビルドし、Cloudflare PagesやGitHub Pagesに静的ファイルをのせて動かせば十分だと思います。 例えば僕が先日作った個人開発のサービスもReact on Cloudflare Pagesの完全なSPAですが、SSRが必要な要素はまったくありません。

Chakraは詰め込みすぎだけど、tailwindのheadlessuiは貧弱すぎ、、という中でまさに欲しかったものが出てきたので簡単に紹介。 2023/01/26更新： 本記事は書かれてから時間が経っており、自分の認識が変わった部分もあるのでアップデートを記載しました。 Radix is 何 Radix（読み方:レイディックス）は、次世代のheadless uiコンポーネントです。headlessというのはstyleがあたっていないということで、UIを「見た目」と「振る舞い」に分けた時、「見た目」が取り除かれているようなイメージです。似た既存ライブラリだとtailwindのheadlessuiが近いですが、より完成度や網羅性が高い印象です。 radix-ui配下には、メインのコンポーネント群であるPrimitives、カラーシステムを提供するColors、Icon群を提供するIconsが

nextjs.org github.com すべては上記のドキュメントとサンプル通りなのですが、useRouterとrouter.eventsを使えば、ページ遷移時にコールバックイベントを設定することができます。 import { useRouter } from 'next/router'; export default function Page() { const router = useRouter(); useEffect(() => { router.events.on('routeChangeComplete', handleChangeRoute); return () => { router.events.off('routeChangeComplete', handleChangeRoute) } }, []); function handleChangeRoute (

はじめに 「React で再レンダリングを抑えたい...」となった場合、多くの人が React.memo や useMemo、useCallback などのいわゆる 「メモ化」 を思い浮かべることでしょう。 しかし、そういった「メモ化」を用いなくても再レンダリングを抑える方法が実は存在しています。 今回はその代表的な例を２つ紹介していきたいと思います。 よくある例 まず例として、以下のような 「パフォーマンスに問題を抱えたコンポーネント」 を考えてみましょう。 import { useState } from "react"; export default function App() { let [color, setColor] = useState("red"); return ( <div> <input value={color} onChange={(e) => setColo

はじめに 複数の要素に対してIntersection Observerで同じ挙動をさせるのにカスタムフックがあると便利だなと思ったので実装してみました。もちろん、単体の要素にも使えます。React + TypeScriptで実装してます。 Intersection Observer とは ページをスクロールして要素がビューポート内に表示されたタイミングで要素をふわっと表示させるアニメーションをさせたい場合などに使います。 交差オブザーバー API (Intersection Observer API) は、ターゲットとなる要素が、祖先要素または文書の最上位のビューポートと交差する変化を非同期的に監視する方法を提供します。 カスタムフックの実装 import { RefObject, useEffect } from 'react' /** * @param refs Intersectio

遅延読み込み React.lazy React Suspenseとは？ エラー境界 Suspenseの使い方 注意点 最後に 遅延読み込み 遅延読み込みは、最適化手法やデザインパターンの一つです。 それは画像、ビデオ、Webページ、音楽ファイル、ドキュメントなど、必要になるまで読み込みを遅らせて貴重なデータを節約する手法です。 通常、Reactのシングルページアプリケーション（SPA）は小さいため、問題なく動作します。しかし、コンテンツ管理システムなどの複雑なアプリケーションを扱う際には、プログラム全体を一度に読み込むことは理想的ではありません。 そこで、Reactアプリケーションを本番用にする前に、Webpackなどのプリインストールされたバンドラーを使用してプロジェクトをパッケージ化します。 しかし、このパッケージ化されたプロジェクトを読み込むと、ユーザーが滅多にアクセスしないページも

Suspense Fetchを3年実用してみて 2023/06/29 Encraft #4 @yoshiko_pg 1

こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく

こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Componentのディレクトリ構成」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいてうまくいっていると感じているComponentのディレクトリ構成についてご紹介していきます。 ディレクトリ構成 Componentは src/components の中にまとめていて、その下に以下の4種類の分類ディレクトリを切っています。 src/components/page src/components/model src/components/ui src/components/functional 分類ディレクトリを考えるにあたって重視したポイントは以下。 新しくco

こんにちは、よしこです。 株式会社ナレッジワーク というスタートアップで、2020年4月の創業時から一人目のフロントエンドエンジニアをしています。 初期に考えて組み上げたスタックで1年半ほど開発・運用してみて、なかなか快適に日々開発ができているので 新規開発のプロダクト立ち上げ時にどのようにフロントエンドを構築したのか？ 立ち上げから1年以上開発・運用を続けてきた今、それらの選択はどうだったのか？ を記事にして振り返り、公開したいなと思いました。 （プロダクトの内容はステルスで進めていてあまり対外的な発信ができないので、かわりに技術的なところはどんどんオープンにしていきたいなという気持ちがあります） いろいろな項目ごとに振り返りたいので、この記事は各項目を横断するindexとして項目ごとの概要を簡単に説明し、深堀りは項目ごとに追って詳細な記事を書いていく予定です！ 前提 プロダクトとしての

mutexの桝田です！ Reactのデータフェッチに、Vercel社が提供する「SWR」やTanStackコミュニティが提供する「React Query（TanStack Query）」が使われることが多くなってきています。 これらのライブラリは単なるフェッチだけでなく、キャッシュやデータの更新を担ってくれます。また、Reactが志向する「宣言的」な記述を体現できることも大きなメリットです。 本稿では、（我々が採用する）React Queryにフォーカスし、React Queryを使って実現している状態管理について説明します。SWRを普段お使いの方に関してもかなり共通する部分が多いのではないかと思います。 1. 対象読者 Reactのデータフェッチライブラリの使用を検討している方 普段SWRやReact Queryを使用している方 普段Reactを使用するすべての方

try { const data = await fetchSomething(); // 正常系レスポンスの処理 } catch (err) { if (isAxiosError(err)) { // 異常系レスポンスの処理 } } 動機はつぎの 3 つです。 データ取得も宣言的に書きたいから データ取得に関係ない例外も catch してしまうから HttpError の集計に不便だから データ取得も宣言的に書きたいから 要約すると、データ取得時は常にこのように書きたい、という話です。useSWR・useQuery や apollo/client でお馴染みのインターフェイスです。 const { data, err, status } = await fetchSomething(); if (data) // 正常系レスポンスの処理 if (err) // 異常系レスポンスの処理

フロントエンド開発は一般的に複雑性との戦いです。放ったらかしにしておくとますます複雑になり、変更するのが難しくなります。これまでにも、このような複雑さをどうにかして制御しようとして、Atomic Designをはじめとした様々な設計手法（デザインパターン）が考えられてきました。 しかし、React / Next.js を使ってチーム開発を行う際に、現状のデザインパターンでの運用では「どうもうまくいかないな」と思う場面に多々遭遇しました。そのような経験を踏まえて、「コンポーネントをどのように設計するか」「どのようにディレクトリを分けるか」を徹底的に考え、新しいデザインパターン「Tree Design」にまとめました。 Tree Design はまだまだ仮説段階です。今後弊社チームで運用していく中でブラッシュアップする予定です。しかし、他のフロントエンド開発チームがデザインパターンを再考する際

みなさんこんにちは。筆者は最近Recoilを使ってロジックを記述するのにハマっています。先日はそのようなテーマでトークをしましたので、よければご覧ください。 要点は、 Recoilのselectorとかも活用しまくってロジックをどんどんRecoilに載せようぜ！！ ということです。ただ、前記のイベントを観ていただいた方には分かるように、Recoilを活用していてもほとんどatomしか使っていないという場合もあり、Recoilの普及度とselectorの普及度には差があるようです。 そこで、この記事ではRecoil selectorの活用パターンを紹介します。今回は無限スクロールの実装です。 ここで想定している無限スクロールとは、次のようなものです。 サーバーから取得したデータがリストで表示されている。 ユーザーがスクロールしてリストの下に到達したら、サーバーから追加のデータを読み込んでリス

ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理