一休レストランの XState 導入記 - 一休.com Developers Blog
このエントリーは 一休.comのカレンダー | Advent Calendar 2023 - Qiita の22日目の記事です。 レストランプロダクトUI開発チームの鍛治です。 一休レストランのフロントエンドを担当しています。 一休レストランでは Next.js App Router Remix を採用しています。 user-first.ikyu.co.jp 昨年の終わり頃から始まった一休レストランのリニューアルですが、フロントエンドは Nuxt v2 (Vue 2) から Next.js App Router (React) に、という大きな切り替えで、不慣れだった我々は React 初心者がひっかかる落とし穴を全部踏み抜いてきました。 例えば、チュートリアルに従って useState で変化する状態を定義して、最初はそれで全てがうまくいっていました。機能追加していく過程でいつの間にか一
「React Journey」から学ぶ React のレンダリングの仕組み
はじめに 「React Journey」 と呼ばれる React においてコンポーネントがブラウザに表示されるまでどのようなプロセスを踏むのか？を示した図 が非常にわかりやすかったので、説明を加えながらみなさんに紹介したいと思います。 レンダリングの流れについて理解が曖昧な人は、ぜひ最後までご覧ください。 対象読者 ある程度 React を触っているが、もっとレンダリングについて理解したい人 公式ドキュメントの「レンダーとコミット」や「state はスナップショットである」などを読んだことがない人 React における「レンダリング」について 本題に入る前に、React を学習していると混乱しやすい「レンダリング」と呼ばれる概念をまず整理しておきましょう。 以下の記事にも書いてありますが、「レンダリング」という言葉はしばしば次の２種類の意味で使用されます。 ブラウザへ画面を表示させること
フロントエンドのディレクトリ設計思想
はじめに フロントエンドのディレクトリ構成、世の中に色んな「推し」が有って悩みますよね。 例えば、、、 さらに最近は、App Directoryの登場や、それに合わせたNext.js公式の「推し」構成がドキュメント化されたりと、さらに色々なパターンが出てきています。 本記事の趣旨 本記事では、具体的な構成そのものではなく、 様々ある構成を横串で見通して整理できる設計思想を紹介します。 新しい推し構成の紹介ではなく、構成を考えたり決めたりするときに役立つ抽象的・汎用的な指針を提供できればと考えています。 基本となる考え 分割の方向 一般的に、アーキテクチャにおける分割には2つの方向が有ります。 (出典も良書なのでリンクを貼っておきます： https://www.amazon.co.jp/dp/4873119820) これはディレクトリにおいても同じだと思っていて、筆者は分かりやすさのために
Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約
Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約 はじめに 10 月 26 日に Next.js Conf が開催されましたが、それと前後して Kent C. Dodds (以下 kentcdodds と呼びます) と Lee Robinson (以下 leerob と呼びます) がそれぞれ という記事を公開しました。前者はタイトルの通り、Testing Library の作者であり、Remix の共同創業者の一人でもある開発者兼教育者 kentcdodds が、Next.js を使わない理由について述べたものです。そして後者は、Vercel の VP of Developer Experience である leerob が、主に前者に対する反論を述べたものです。筆者は両方の記事を公開後すぐに面白く読み、そしてどちらにも頷けるところ
ブラウザバックで壊れないstate管理を実現する`location-state`
この記事は最近リリースしたlocation-stateというライブラリの紹介記事です。 モチベーション Reactのstate管理は、様々な分類が可能です。筆者が過去に書いた記事「スコープとライフタイムで考えるReact State再考」では、stateの分類は大きく以下2つの観点で分類ができると述べました。 スコープによる分類 ライフタイム（=stateの生存期間）による分類 詳しく知りたい方はこの記事を読んでいただきたいのですが、今でもstate管理というと多くの場合スコープによる分類の話が多く、ライフタイムによる分類の話はあまり聞かない気がします。 なぜライフタイム観点が重要か ライフタイムを意識せずに実装した場合に発生するのが、遷移時に状態が破棄され復元されない、つまりブラウザバックでstateが壊れるという問題です。この問題については以下の記事で、Vercelの社長が2014年に
Reactで再レンダリングを抑えるシンプルな方法
はじめに 「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
10万件のSelectBoxが作りたい
10秒で概要 10万件のデータをサジェストするAutocompleteなSelectBoxを作りたい。 しかし、1万件を超えたあたりから通常のAutocompleteではレンダリングに時間がかかる。 以下の方針が有る。 react-windowによるレンダリング以外の範囲の仮想化 フロントエンドではデータを保持せず、入力値に応じてSearchのAPIコールを実施する Reactのレンダリングによる課題 Reactのレンダリングは、大まかに以下のフローで行われます。 Triggering a render 新規画面への描画時、またDOM要素の差分を検出したことをTriggerがとして、レンダリングが発生します。 Committing to the DOM 描画要素に違いがあるDOM要素のみ、DOMノードを変更します。 Autocompleteで表示するデータである<li>要素についても当然D
非制御フォームをやるならこんなふうに Recoil編
Reactにおいて、フォームをどのように実装するかというのは開発者の悩みの種のようです。筆者は最近ロジックをRecoilに載せるのにはまっていますので、今回はRecoilを使ってフォームを実装することを考えてみます。 制御コンポーネントと非制御コンポーネント Reactにおいてフォームの実装方法は2種類に大別されます。それは、制御コンポーネント (controlled components) を使うか非制御コンポーネント (uncontrolled components) を使うかです。制御コンポーネントとは、入力されたテキスト等をReactのステートとして保持し、<input value={state} />のようにinput等のvalueに渡してレンダリングする方法です。制御コンポーネントではデータの本体がReact側にあり、DOMはそれを写像しているだけです。一方、非制御コンポーネン
「Recoil selector活用パターン 無限スクロール編」のJotai版
を見ました。これめっちゃ面白い。再帰selectorかっこいい、ほれました。Loadableの使い方も素敵。 Jotai版を作ってみたくなりますよね、はい。作りました。 ほとんどコードの中身を理解せずに移植して、あとからコード読みました。ちなみに、移植で大変だったのは、型の付け方が微妙に違うことです。それ以外はほぼ単純な変換。ここまで互換性があったとは。 出来上がったもの コード Recoil版からそのまま使えるものはimportしてます。 import { Suspense, useEffect, useRef } from "react"; import { Atom, atom, useAtomValue, useSetAtom } from "jotai"; import { atomFamily, loadable } from "jotai/utils"; import { Q
React の状態管理ライブラリ9選
はじめに 次から次へと登場する状態管理ライブラリですが、それだけ React (に限った話ではないが) において状態管理というのは大きなテーマであり、最も実装難易度の高いトピックの一つでしょう。適切な設計ができないとアプリケーションの規模が大きくなるにつれ負債は増え続けます。 状態管理の難しさをよく表した文章が Redux の公式サイトにあるためお借りしたいと思います。(Redux の公式サイトは読み物としても面白いです) JavaScript のシングルページアプリケーションの要件がますます複雑になるにつれて、コードはこれまで以上に多くの状態を管理する必要があります。この状態には、サーバーのレスポンスやキャッシュされたデータ、まだサーバーに永続化されていないローカルに作成されたデータなどが含まれます。UI の状態も複雑化しており、アクティブなルート、選択されたタブ、スピナー、ページネーシ
データ取得のための React Hooks ライブラリ – SWR
import useSWR from 'swr' function Profile() { const { data, error, isLoading } = useSWR('/api/user', fetcher) if (error) return <div>failed to load</div> if (isLoading) return <div>loading...</div> return <div>hello {data.name}!</div> } この例では、useSWR フックは key 文字列と fetcher 関数を受け取ります。 key はデータの一意な識別子（通常は API の URL）で、fetcher に渡されます。 fetcher はデータを返す任意の非同期関数で、ネイティブの fetch や Axios のようなツールを使うことができます。 このフッ
Remix - Build Better Websites
Focused on web standards and modern web app UX, you’re simply going to build better websites Remix is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience. People are gonna love using your stuff. export async function loader({ request }) { return getProjects(); } export async function action
input[type=number] のステートを安易に number 型にしない - fsubal
input[type=number] には空文字とかも入力できるので、string 型で状態管理をしないと意図しない動きをすることがある
![input[type=number] のステートを安易に number 型にしない - fsubal](https://cdn-ak-scissors.b.st-hatena.com/image/square/7158ad1623f38d46fa16bc786647d6587a63a968/height=288;version=1;width=512/https%3A%2F%2Fscrapbox.io%2Ffiles%2F633ade0e2efe22001d60e1ea.gif%3Ftype%3Dthumbnail)
Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか Reactを取り巻く状態管理のアプローチは変化を続けていますが、いま知っておくべき手法とはどのようなものでしょうか。小林 徹（@koba04）さんに、現在、そしてこの先の状態管理について執筆いただきました。 こんにちは、小林（@koba04）です。 2019年5月に『SPAにおける状態管理:関数型のアプローチも取り入れるフロントエンド系アーキテクチャの変遷』という記事を書きましたが、そこから2年以上が経過し、Reactを用いた状態管理は大きく変わりました。本記事ではReactを取り巻く状態管理の変遷について解説します。 広がるReduxの採用 Hooksの登場 コンポーネントツリーから独立した状態管理 Concurrent Featuresによる新しいユーザー体験 状態とキャ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - lukasbach/react-complex-tree: Unopinionated Accessible Tree Component with Multi-Select and Drag-And-Drop
GitHub - BetaSu/big-react: 跟着我，从0实现React18
GitHub - reactive-python/reactpy: It's React, but in Python
Radix UI
Mantine
GitHub - xyflow/xyflow: React Flow | Svelte Flow - Powerful open source libraries for building node-based UIs with React (https://reactflow.dev) or Svelte (https://svelteflow.dev). Ready out-of-the-box and infinitely customizable.
