Agent Skills by ALSEL
Anthropic Claudeその他⭐ リポ 0品質スコア 50/100

render-props-pattern

JSXを返す関数をpropとして渡すことでコンポーネント間のレンダリングロジックを共有する、render propsパターンを解説します。柔軟なコンポーネント合成が必要な場面や、複数のコンポーネントでレンダリングロジックを再利用したい場合に活用してください。

description の原文を見る

Teaches the render props pattern for flexible component composition. Use when you need to share rendering logic between components by passing a function that returns JSX as a prop.

SKILL.md 本文

Render Props パターン

目次

コンポーネントの再利用性を高めるもう一つの方法は、render props パターンを使うことです。render prop はコンポーネントのプロップで、JSX 要素を返す関数を値として持ちます。このコンポーネント自体は render prop 以外に何もレンダリングしません。代わりに、コンポーネントは独自のレンダリングロジックを実装する代わりに、単に render prop を呼び出すだけです。

Title コンポーネントがあると想像してください。この場合、Title コンポーネントは渡された値をレンダリングすること以外には何もしません。これに render prop を使うことができます!Title コンポーネントにレンダリングさせたい値を render プロップに渡します。

使用する場面

  • 異なるレンダリング要件を持つコンポーネント間でステートフルロジックを共有する必要がある場合に使用します
  • HOC パタームが命名の衝突問題や過度なネストを引き起こす場合に有効です

使用しない場面

  • カスタムフックでパターンを置き換えられるとき — フックは render prop のネストなしで同じロジック再利用を提供します
  • 深くネストされた JSX が生成され、読み書きが難しくなるとき
  • 共有ロジックが単純なユーティリティ関数またはフックで十分なとき

手順

  • 関数を render プロップ(または children プロップ)として渡し、データを受け取り JSX を返すようにします
  • 最新の React コードではほとんどの場合、render props よりカスタムフックを使うことを推奨します
  • 明示的な render プロップの代わりに、関数としての children パターンをより清潔な代替案として使用します
  • 複数の render prop コンポーネントの深いネストを避けてください — 代わりにフックへのリファクタリングを行います

詳細

<Title render={() => <h1>I am a render prop!</h1>} />

Title コンポーネント内では、呼び出された render プロップを返すことでこのデータをレンダリングできます!

const Title = (props) => props.render();

render props と呼ばれていますが、render prop は必ずしも render と呼ばれる必要はありません。JSX をレンダリングするすべてのプロップが render prop と見なされます!

render prop を受け取るコンポーネントは通常、render プロップを単に呼び出す以上のことをします。代わりに、render prop を受け取るコンポーネントから、render prop として渡す要素にデータを渡したいことがほとんどです!

function Component(props) {
  const data = { ... }

  return props.render(data)
}

render prop はこのプロップを引数として受け取ることができます。

<Component render={data => <ChildComponent data={data} />}

例を見てみましょう!ユーザーがセルシウス温度を入力できるシンプルなアプリがあります。アプリはこの温度をファーレンハイトとケルビンの値で表示します。

現在、問題があります。ステートフルな Input コンポーネントがユーザーの入力値を保持しているので、FahrenheitKelvin コンポーネントはユーザーの入力にアクセスできません!

ステートの持ち上げ

ユーザーの入力を FahrenheitKelvin コンポーネントの両方で利用できるようにする一つの方法は、ステートを持ち上げることです。

この場合、ステートフルな Input コンポーネントがあります。しかし、兄弟コンポーネントの FahrenheitKelvin もこのデータにアクセスする必要があります。ステートフルな Input コンポーネントの代わりに、InputFahrenheitKelvin に接続できる最初の共通祖先コンポーネント(この場合は App コンポーネント)にステートを持ち上げることができます!

function Input({ value, handleChange }) {
  return <input value={value} onChange={(e) => handleChange(e.target.value)} />;
}

export default function App() {
  const [value, setValue] = useState("");

  return (
    <div className="App">
      <h1>☃️ Temperature Converter 🌞</h1>
      <Input value={value} handleChange={setValue} />
      <Kelvin value={value} />
      <Fahrenheit value={value} />
    </div>
  );
}

これは有効なソリューションですが、多くの子を処理するコンポーネントを持つ大規模なアプリケーションでステートを持ち上げるのは難しい場合があります。各ステート変更は、データを処理していないコンポーネントを含むすべての子の再レンダリングを引き起こす可能性があり、これはアプリのパフォーマンスに悪い影響を与える可能性があります。

Render props

代わりに、render props を使うことができます!Input コンポーネントを render props を受け取るように変更しましょう。

function Input(props) {
  const [value, setValue] = useState("");

  return (
    <>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
        placeholder="Temp in °C"
      />
      {props.render(value)}
    </>
  );
}

export default function App() {
  return (
    <div className="App">
      <h1>☃️ Temperature Converter 🌞</h1>
      <Input
        render={(value) => (
          <>
            <Kelvin value={value} />
            <Fahrenheit value={value} />
          </>
        )}
      />
    </div>
  );
}

完璧です!KelvinFahrenheit コンポーネントはユーザーの入力値にアクセスできるようになりました!

関数としての children

通常の JSX コンポーネントの代わりに、関数を React コンポーネントの子として渡すことができます。この関数は children プロップを通じて利用できます。これは技術的には render prop でもあります。

Input コンポーネントを変更しましょう。明示的に render プロップを渡す代わりに、Input コンポーネントの子として関数を渡すだけです。

export default function App() {
  return (
    <div className="App">
      <h1>☃️ Temperature Converter 🌞</h1>
      <Input>
        {(value) => (
          <>
            <Kelvin value={value} />
            <Fahrenheit value={value} />
          </>
        )}
      </Input>
    </div>
  );
}

Input コンポーネント上で利用可能な props.children プロップを通じて、この関数にアクセスできます。ユーザー入力の値で props.render を呼び出す代わりに、ユーザー入力の値で props.children を呼び出します。

function Input(props) {
  const [value, setValue] = useState("");

  return (
    <>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
        placeholder="Temp in °C"
      />
      {props.children(value)}
    </>
  );
}

素晴らしい!この方法で KelvinFahrenheit コンポーネントは render プロップの名前について心配することなく値にアクセスできます。

フック

場合によっては、render props をフックで置き換えることができます。その良い例が Apollo Client です。

Apollo Client を使う一つの方法は MutationQuery コンポーネントを通じることです。Mutation コンポーネントからデータが必要な要素にデータを渡すために、関数を子として渡します。この関数は引数を通じてデータの値を受け取ります。

<Mutation mutation={...} variables={...}>
  {addMessage => <div className="input-row">...</div>}
</Mutation>

render props パターンを使い続けることはでき、高階コンポーネントパターンと比べて好まれることが多いですが、欠点があります。

欠点の一つは深いコンポーネントネストです。コンポーネントが複数のミューテーションまたはクエリにアクセスする必要がある場合、複数の Mutation または Query コンポーネントをネストすることができます。

<Mutation mutation={FIRST_MUTATION}>
  {(firstMutation) => (
    <Mutation mutation={SECOND_MUTATION}>
      {(secondMutation) => (
        <Mutation mutation={THIRD_MUTATION}>
          {(thirdMutation) => (
            <Element
              firstMutation={firstMutation}
              secondMutation={secondMutation}
              thirdMutation={thirdMutation}
            />
          )}
        </Mutation>
      )}
    </Mutation>
  )}
</Mutation>

フックのリリース後、Apollo は Apollo Client ライブラリにフックサポートを追加しました。MutationQuery の render props を使う代わりに、開発者はライブラリが提供するフックを通じて直接データにアクセスできるようになりました。

useQuery フックを使うことで、コンポーネントにデータを提供するために必要なコード量を削減しました。

メリット

render props パターンを使って複数のコンポーネント間でロジックとデータを共有するのは簡単です。render または children プロップを使うことで、コンポーネントは非常に再利用可能にすることができます。高階コンポーネントパターンは主に同じ問題(つまり 再利用性データ共有)を解決しますが、render props パターンは HOC パターンを使うときに遭遇する可能性がある問題のいくつかを解決します。

HOC パターンを使うことで遭遇する可能性のある 命名の衝突 の問題は、render props パターンを使うことではもはや適用されません。プロップを自動的にマージしないからです。親コンポーネントから提供された値を持つプロップを明示的に子コンポーネントに渡します。

プロップを明示的に渡すため、HOC の暗黙的なプロップの問題を解決します。子要素に渡すべきプロップはすべて render prop の引数リストに表示されます。このようにして、特定のプロップがどこから来ているのかが正確にわかります。

render props を通じてアプリのロジックをレンダリングコンポーネントから分離できます。render prop を受け取るステートフルコンポーネントは、単にデータをレンダリングするステートレスコンポーネントにデータを渡すことができます。

デメリット

render props で解決しようとした問題は、大部分が React フックに置き換わっています。フックがコンポーネントに再利用性とデータ共有を追加する方法を変えたため、多くの場合 render props パターンを置き換えることができます。

render prop にライフサイクルメソッドを追加することができないため、受け取るデータを変更する必要がないコンポーネントでのみ使用できます。

出典

参考資料

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者
patternsdev
リポジトリ
patternsdev/skills
ライセンス
MIT
最終更新
不明

Source: https://github.com/patternsdev/skills / ライセンス: MIT

関連スキル

汎用その他⭐ リポ 1,982

superfluid

Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード:Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool(member/distributor)、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper

by LeoYeAI
汎用その他⭐ リポ 100

civ-finish-quotes

実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。

by huxiuhan
汎用その他⭐ リポ 1,110

nookplot

Base(Ethereum L2)上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。

by BankrBot
汎用その他⭐ リポ 59

web3-polymarket

Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。

by elophanto
汎用その他⭐ リポ 52

ethskills

Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格(ERC-20、ERC-721、ERC-4626など)、Layer 2ネットワーク(Base、Arbitrum、Optimism、zkSync、Polygon)、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化(EIPライフサイクル、フォーク追跡、今後の変更予定)といったトピックを含みます。

by jiayaoqijia
汎用その他⭐ リポ 44

xxyy-trade

このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。

by Jimmy-Holiday
本サイトは GitHub 上で公開されているオープンソースの SKILL.md ファイルをクロール・インデックス化したものです。 各スキルの著作権は原作者に帰属します。掲載に問題がある場合は info@alsel.co.jp または /takedown フォームよりご連絡ください。
原作者: patternsdev · patternsdev/skills · ライセンス: MIT