React の useEffect の実行タイミングについて、このように思っていませんか？ 依存配列（第2引数として渡す配列）を省略したら、マウント時に、そのあと再レンダーごとに実行される 依存配列に空配列を入れたら、マウント時に実行される 依存配列に値を入れると、マウント時と、値が変わるごとに実行される しかもクリーンアップ関数も絡んで来て、もっと複雑で覚えられない… …そのように考える必要はありません。 実は、useEffect の規則は至ってシンプルで、しかも UI ロジックの頻出の課題を洗練されたパターンに落とし込んで解決してくれます。 エフェクトとクリーンアップの実行タイミングは、以下のように論理的にシンプルな形で捉えることができます。 マウント時 に初回のエフェクトが発火され、アンマウント時 に最後のクリーンアップが実行される。 再レンダリング時 に、前回のエフェクトをクリーン

オブジェクトの中に、定数をフラットに列挙しただけの定数ファイルを書いていませんか？ 私は、フロントエンドの開発において、 JavaScript の簡潔なオブジェクト記法 TypeScript による型チェック / IDE 等による入力補助 を活用した保守性の高い定数ファイルの書き方を日夜研究しているので、4つのポイントに着目して解説しようと思います。 この記事で求める「保守性」 網羅的に視認しやすいこと 会社/文化によって異なるかも知れませんが、 「全てのフィールド（ラベル・説明文・バリデーションエラー文言）」のような情報が仕様ドキュメントの中でまとめて管理されている状況では、コードの側でも文書の構造に合わせて情報をまとめて配置すれば、仕様と実コードを見比べるのがラクになるのかな...？と考えています。 また、単純に仕様上重要な情報がボリューミーなコードの中に埋もれやすいので、定数ファイル

はじめに プロジェクトに参加しているメンバーがうまく環境に適用できずに離脱することがあり、ともすれば、身体を壊してしまうケースもあります。これは新規メンバーに限定されず、既存のメンバーでも、プロジェクトや本人の状況、その役割が変われば発生し得ると思っています。 そういったことを回避できた状態を想像した時にプロジェクトに浅瀬があったら良いのではというイメージからこの言葉が浮かんだのだと思います。2年ほど前のメモ書きにこのタイトルが残されていて、今見直した時にすごくしっくり来ました。 メモ書きを発見したツイート この「プロジェクトに浅瀬を作る」とは、どういうことなのか、改めて深堀したいと思います。 どういうこと？ 溺れないようにするのが目的 監視員が必要のない状態が理想 溺れないようにするのが目的 溺れるというのは、闇雲に時間がかかってしまい心身ともに疲弊してしまうイメージです。不慣れなため必