訳語の統一

訳語は以下のルールに従ってください。

• Effect/side effect: 新サイトからは先頭大文字の Effect（useEffect によるもの）を「エフェクト」、小文字の side effect（一般的なプログラミングの概念）を「副作用」として使い分ける。経緯については #585 を参照。
• dependency: エフェクトや useMemo などの文脈で出てくるこの語は、文脈に応じて「依存値」（配列内の個々の要素を指している場合）または「依存配列」（配列そのものを指している場合）とする。原文でも dependency/dependencies が配列そのものを指している場合と個々の値を指している場合があり曖昧なことがあるため、適宜文脈から読み取って訳す。"npm install" などで入れる dependencies は「依存ライブラリ」とする。
• props/prop/property: 文脈によって使い分ける。
  • カスタムコンポーネントのパラメータとしての props を指している場合は「props」。単数形の「prop」を訳語に使うのは避けるが、例えば "send it as a prop" を「props の一部として伝える」などと訳出しても可。例外として特定のプロパティを指す "the fooBar prop" は 「fooBar プロパティ」とする。
  • それ以外の文脈では「プロパティ」「特性」などを適宜使い分ける。特にプレーンな JavaScript オブジェクトのプロパティを指している場合まで props としない。
• state: 文脈により使い分ける。
  • カスタムコンポーネントが管理する React の機能としての state を指している場合は「state」とする。アルファベットを使うのはクラスコンポーネントにおける props との対称性から。フックが広まると「ステート」で統一してもよくなるかもしれないが、時期尚早なので当面はアルファベットで。例外としてトップページ (index.md) はドキュメントというよりは宣伝文であることを考慮し「状態」を使う。"stateless" は「ステートレス」または「state を持たない」、"stateful"は「ステートフル」または「state を持つ」「state を使う」などとする。
  • それ以外の文脈でおぼろげにアプリケーションの状態や Redux のストアが保持している状態を指している場合は「状態」または「ステート」を使う。
• key: 文脈により使い分ける。
  • React のリストの子要素を区別するためのヒントである key 属性を指す場面では「key」とする。
  • それ以外の文脈ではアルファベットにせず、「キー」「鍵となる」「重要な」などを使い分ける。特にプレーンな JavaScript オブジェクトの文字列／数値キーを key としない。
• ref: React の機能としての ref は「ref」とする。
• render: 文脈により使い分ける。
  • 関数コンポーネントの本体の呼び出しにより React 要素を構築する作業のことを指している場合は「レンダー」。3 音以上の単語であるが例外として「レンダ」としない。原文での活用形にかかわらず「レンダリング」は使わない。"during the rendering" は「レンダー中」。ただし Server-side Rendering などの固定用語は「サーバサイドレンダリング」としてよい。
  • 古いドキュメントで、React 要素から DOM を構築することやブラウザが画面を描画することを render と呼んでいる場合があるが、これらは「表示」「変換」「ペイント」などを適宜使用し、むしろ「レンダー」は使用しない。極端な例としては：

    A component renders props into a React element, which React DOM renders into DOM elements, which your browser renders to the screen.
    コンポーネントは props を React 要素にレンダーし、それを React DOM が DOM 要素へと変換し、それをブラウザーが画面にペイントします。

  • renderer は「レンダラ」。これは上記の例外であり、React 要素を別のもの（DOMElementとか）に変換するのが役目であるが、まさか「変換器」にするわけにも行かないので「レンダラ」で。
• context: React の機能としての context は「コンテクスト」。「コンテキスト」としない。
• fragment: React の機能としての fragment (<>) は「フラグメント」。
• function(al) component: 「関数コンポーネント」。「関数型コンポーネント」としない。原文でも function component に統一する方向。
• controlled component / uncontrolled component: 「制御されたコンポーネント」「非制御コンポーネント」。
• render props: 「レンダープロップ」。
• pure function: 「純関数」。「純粋関数」としない。
• escape hatch: 「避難ハッチ」。
• propagate/propagation: 「伝播」。「伝搬」としない。
• hook: 「フック」。「ホック」「Hook」としない。
• composition / compose: 設計思想を特異的に表す場合は「コンポジション」を使うが、文章中では「組み合わせ」「組み立て」などを適宜使用してよい。
• declarative: 「宣言型（の）」。
• imperative: 「命令型（の）」。declarative の対義語。「命令形（の）」「命令的」「手続き型（の）」としない。
• single source of truth: 「信頼できる唯一の情報源」。原文併記推奨。
• source of truth: 「信頼できる情報源」。原文併記推奨。
• development/production build/environment/version: 「開発用／本番用ビルド」「開発用／本番（用）環境」「開発用バージョン／本番用バージョン」
• codemod: 「codemod」。個々の mod が普通名詞であるかのように扱われる場合 "codemods" となっていることがあるが、日本語では「codemod」で統一。
• import/export: 「インポート」「エクスポート」。「エキスポート」としない。
• ancestor: 「祖先」。「先祖」や「上位」としない。
• developer: 「開発者」。
• concurrent: 「並行」。「並列」としない。過去に Concurrent Mode の訳を「並列モード」としていたが、今後は「並行」に統一。これらの違いについては #422 を参照。
• returns; return value：「返り値」。「戻り値」としない。

いわゆる React 用語や重要かつ汎用的なプログラミング概念に対しては、以下のようなスタイルでファイル毎に初出時に原文を併記することを推奨。

• 高階コンポーネント␣(higher-order component;␣HOC)␣の作成
• "信頼出来る唯一の情報源␣(single source of truth)"␣の原則に従いましょう。

もちろん「クラス」「コンポーネント」などのお馴染みの用語は英文併記は不要。

---

以下は古いドキュメントにしか出てこないと思われる用語。

• reconciliation/reconciler: 多くの記事では単に「差分検出処理」とし、細かい実装（Fiberなど）に踏み込んだ上級者向け記事でこの単語が何度も出てくる場面では「リコンシリエーション」「リコンサイラ」とする。ニュアンスとしては「違っているところを擦り合わせて合致させること」という用語。
• higher-order component: 「高階コンポーネント」。「高次コンポーネント」としない。