useEffect を使って「初回以外の再レンダリング時に実行される処理」を書くにはどうすれば良いのか？ という疑問を、たまに目にします。 たとえば、以下のような仕様の、「商品価格を編集する画面」を作ることを考えてみましょう。 日本での販売価格入力 ページ読み込み時には初期値が入っている アメリカでの販売価格入力 ページ読み込み時には、初期値が入っている 日本での販売価格入力に入力するたび、その1/100の値が自動で入力される あくまで、入力の参考にするため、というイメージ この欄に入力すれば、上書きできる そもそも、こういった自動入力は「入力するたび」ではなく、「フォーカスを外したとき」にするのが定石だと思いますが、 useEffect の話がしたいので、あえてこのような仕様に設定しています。 ❌️ useEffect を使って変更検知しようとすると暴発する 《日本での販売価格 japa

<div className={style.buttons}> <Button type="button" color="secondary" startIcon={<FiRotateCcw size={18} />} > キャンセル </Button> <Button type="submit" color="primary" startIcon={<FiCheckCircle size={18} />} > 次に進む </Button> </div> このボタンの仕様はざっくりと以下の通りです。 color Prop は以下の2通りの文字列を指定可能 "primary" … 青い背景、白文字 "secondary" … 薄灰色の背景、黒文字 startIcon Prop として ReactNode を渡せる 省略可。渡されたアイコンを、ラベルの左側に配置する つまり、「コンポジション」

React Hook Form の場合 いきなりですが、下のコードを見てください。 「姓」と「名」の入力フィールドがあって、その下にある「ちゃんと再計算される氏名」に続いて姓と名をつなげた文字列が出力されます。 「ちゃんと再計算される氏名」は、姓および名を入力するたびにキチンと更新されます。 "use client"; import { type FC } from "react"; import { useForm } from "react-hook-form"; type ProfileFormValues = { familyName: string; personalName: string; }; const ProfileEditPage: FC = () => { const { watch, // // getValues, register, handleSubmit,

新年明けましておめでとうございます。 2024年もよろしくお願いいたします。 さて、僕の新年の用事は済ませたので、さっそくVSCodeでReactを書いて今年の書き初めとしようと思います。 こちらの記事の重い再レンダリングをReactのトランジション機能で改善できるか試してみました。仕組みは詳しく理解できておらず推測を含みますが、とにかく何とかなったので書き留めておきます。 仮想スクロールを使えば、より確実にパフォーマンス改善できそうな気がしますが、詳しくないし Reactのスケジューリング機構によるパフォーマンス改善を体感してみたかったので今回は触れません。 いつもと違って「新しい使い方を試してみた」主旨の動画なので、useTransition に対する説明が正しいとは限りません。@uhyoさんのこの記事を読んだほうが、解説は詳しいと思います。 「割当て状態を更新」したのをリアルタイムで

Props のバケツリレー (Props Drilling) を解決するときに、安易に Context を使ったり、状態管理ライブラリ(Recoil, Jotai, Redux)に頼っていませんか？ そんなことをせずとも、「CompA が CompB を使い、CompB が CompC を使い、 CompC が ...」という依存関係のチェーンを浅くするのが最善の解決策である場合があります。 「ローカルとはいえない、真にグローバルな状態1 である」なら、Recoil や Jotai が使えますし、 Context には Context の活躍できる場面2 があります。今回はそれらの話はしません。 KISS (Keep It Simple Stupid) という名言があるように、「Props を渡すだけ」というわかりやすい方法を取ることで、将来のコード読解が楽になり、メンテナンスが容易になり

という疑問が出てきたはずです。 これを題材にして、イベントが起きた時の処理を親と子でどのように分けたら良いのか考えてみます。 リセットする責務だけを子に分担させる 親から渡されたイベントハンドラを実行したあとに、 setTitle を使ってステートをリセットします。 import { useCallback, useState } from "react"; import { Button, Grid, Input, Paper, Text, Title } from "@mantine/core"; type Props = { onCreateTodoItem: (newItem: { title: string }) => void; }; const TodoCreateArea: React.FC<Props> = ({ onCreateTodoItem }) => { cons

「Divide and Conquer / 分割統治法」 という解法（アルゴリズムの話でよく出てきますね）は、「困難は分割せよ」 として知られる、デカルトが『方法序説』で提唱した思考法が元になっています1。 第二は、わたしが検討する難問の一つ一つを、できるだけ多くの、しかも問題をよりよく解くために必要なだけの小部分に分割すること。 ―― 岩波文庫 『方法序説』 デカルト著 谷川多佳子訳 同様に、React で多機能で複雑な画面を作りたい時、それを小さな機能の集まりと捉えて、それぞれをコンポーネントにすることで、開発がラクになることがあります。 フロントエンドの複雑さや、デザインのための Atomic Design という考え方の影響、または /scripts のように分ける習慣の名残なのか、フロントエンド開発者には、《再利用のためにコンポーネントを作る》という思い込みがあります。（もしくは

【React】誤解される useMemo と 誤用される useState ―― 「A の変更に反応して B の値が変わる」と考えるべきでない初心者React新人プログラマ応援react-hooksAdventCalendar2022 React において、 「フルネームは、名字と名前をつなげたもの(名字と名前は変わりうる)」 はどのように表せば良いのでしょうか？ useState + useEffect でしょうか？ useEffect は変更検知のためのものではありません。 useState は、「Prop・他のステートが変化するたびに毎回反応する」ような書き方をするのに向いていません。コードは無駄に長くなりますし、SSoT (Single Source of Truth) の原則に則していないので読みづらいです。 むしろ「ほかの値が変わっても、この値は変わらない」というケースに有効で

Mantine UI の TextInput の input 部分だけ横幅を狭めて、ラベル等の横幅は変えない方法formReactMantine 目的 上の図の「郵便番号」欄のように、 最高の桁数が決まっていて、 その桁数が少ない場合 特に PC で表示するとき には、入力欄をその桁数に合わせて狭くするのが一般的なグッド・プラクティスだと認識しています。 Mantine UI の TextInput は、 label, description Props を備えている「全部入り」の文字列入力用コンポーネントですが、 それらの横幅を狭めることなく（長い説明文を折り返さず表示できるようにするため）、入力欄本体の横幅だけを狭くするにはどうすれば良いでしょうか？ 結論 styles prop を使って、 input にスタイルを当てましょう。 <TextInput name="postalCode

「入力内容の確認」画面の実装のつらさ 「入力画面と確認画面のあいだの画面遷移」……それは、全 React エンジニアの敵。(主語がデカい) 入力内容を保持して確認画面に遷移する 確認画面でブラウザの「戻る」ボタンを押した時の挙動のケア サーバー側から返ってくる修正可能なエラー(たとえば、IDが既存と被っている)のケア 確認→入力画面に戻す etc. このように、細かく配慮しようとするとコードの複雑性が加速してしまうのが、React における「入力内容の確認」画面だと思います。 じゃあ、無くしちゃおうか なので、実装者の都合だけを考えるなら、確認画面なんて無くしちゃえば良いのですが、ユーザーの使い勝手を完全に無視してしまうのも気が引けます。 特に、「新しい商品を登録するボタン」「商品を削除するボタン」のように、取り返しの付かないアクション では、ワンクッション置かず急に処理が始まるのは不親切

useEffect とは何か、ご存知ですか？ useEffect？ 知ってるよ。 依存配列に入れた値が変更されるたびに関数が実行されるフックでしょ？ これは半分正解ですが、半分間違っています。 useEffect のデフォルトの挙動は「レンダーのたびに毎回実行」です。 依存配列は「変わった時に実行する」というより「変わらなければスキップ」と捉えたほうが良いかもしれません。 useEffect は再レンダー以外の変化を検知できません。 特にミュータブルなオブジェクトが絡む場合は注意 React 公式のドキュメントの解説を見ながら、以上の2つのポイントに絞って、誤解を解いていこうと思います。 宣伝 useMemo, useState についても記事を書きました。よかったらこちらも確認してください。 2023/10/03 追記: ブラッシュアップしました ブラッシュアップしたので、そちらの記事も

そのファイル、本当に hooks/・utils/ に入れるんですか？ ―― React プロジェクトを蝕む「見かけ駆動パッケージング」設計アンチパターンReact 結論 (2023/06/03 追記) React の開発においては、 コロケーション Co-location の原則に従って、ファイルをディレクトリごとに分類しましょう。チームメイトや将来の自分にとって分かりやすいコードベースになります。 スキット「書くときは楽だけど...」 == 某日 == 太郎くんの今日のタスクは、「トーストを作る」です。 イメージ図 太郎くん 「コンポーネントを作るから..」 「ファイルの場所は components/Toast.tsxでええか。」 「useState でローカルに状態管理して、表示を切り替えればええやろ。」 太郎くん「ヨシ！」 この記事は、拙スクラップの一項目をモノローグ形式で分かりやす

はじめに：この記事を書いた動機 これらの素晴らしい先行記事を見て、「言語学を用いれば、共通点を見つけ出して一般化・大項目化したり、取り違えやすいエッジケースを明確化できるんじゃないか？」と思ったことが、この記事を書き始めたきっかけになります。 １章は３つの主要なパターンとその詳細・例外、２章はそれらに関する文法的な解説になっています。 構造化・体系化が必要な理由 太郎くんと花子さんが英作文の問題を解いています。 次の日本語を英文に訳せ。 (1) 彼女は楽しい人だ。彼女といると退屈することがない。彼女はいつも新しいことに挑戦して…… 太郎くん（『楽しい』って英語で何やったっけ……） 狩井先生@ 1年6月「exciting は楽しいって意味やで～」 ~~ 月日が流れる ~~ 柱鈴先生@ 2年4月「excited は楽しいって意味やで～」 太郎くん（……って教わったけど、exciting か e