React Feature Flags: A Complete Implementation Guide

機能を完成させました。プルリクエストはきれいです。QAは良さそうだと言っています。でも、全員に一度に配信したくないのです。

その気分は、通常、Reactアプリが単純なデプロイから成長した最初の兆候です。製品が実際のユーザーを持つと、リリースは技術的イベントだけではなくなります。リスクの決定になります。新しい検索UIが壊れる、チェックアウトバリエーションがユーザーを混乱させる、またはモバイルビルドがcodeを実行できない場合、迅速に戻すことができない場合、より多くのものが必要になります。 if (process.env.NODE_ENV) そして希望。

それが始まるのは React機能フラグ start to matter. Not as a cute boolean in a component, but as a release control layer that lets you ship code separately from exposing it. In web apps, that means safer rollouts. In bundled apps like Capacitor or Electron, it matters even more because rollback speed is limited by store review, install lag, and slower release cycles.

モダンReactアプリの機能フラグの重要性
- 展開とリリースは異なる仕事
- フラグは信頼されていない場合に役に立たなくなる
Reactアプリの機能フラグの設計
ロールアウトとロールバック戦略の実装
テスト観測性とフラグの負債管理
フラグを保護し、CI/CDを自動化する
Beyond the Web Feature Flags for Capacitor and Mobile Apps
- バンドルアプリはリリースの計算を変える
- フラグは、更新配信と組み合わせると最も効果的です

モダンなReactアプリのための機能フラグの重要性

金曜日の午後、新しい請求概要UIはすでにデプロイされており、サポートはリリースチェックリストを開いており、1つのエンタープライズクライアントは月曜まで古いフローを必要としています。ウェブアプリではすでに緊張感があります。デスクトップインストーラーやモバイルストアを通じて配信されるバンドルされたReactアプリでは、ロールバックが分数より時間かかるか、数日かかるため、状況はさらに悪くなります。

Feature flags give React teams control over that moment. They let you ship the code, keep it dormant, and decide later which users should see it. That changes release work from an all-or-nothing event into a controlled operation.

機能フラグの重要性の説明を示すグラフィック。

デプロイとリリースは異なる仕事です

デプロイは「codeが実行中かどうか」を答えます。リリースは「この行動を実行できるのは誰か」を答えます。

その区別は、リアルなトラフィック、複数の環境、収益、パーミッション、ナビゲーションなどを扱う機能を持つReactアプリが存在する場合に重要になる。チームは早期にマージし、内部コホートでテストし、機能を信頼できるようになったらのみアクセス範囲を拡大できる。Capacitorアプリ、Electronアプリ、ストアレビュー済みモバイルビルドなどのスローページングプラットフォームでは、その制御はすでにユーザーの手元にあるバイナリを待たずに機能をすべてのユーザーに提供できるようになるまでの間、さらに貴重になる。

フラグは、以下の3つのシナリオで役に立つ。

制御されたロールアウト: 新しいパスを小規模なグループに最初に公開する
実験: バリアントを比較するには、別々のデプロイを維持する必要がない
急いでシャットダウン: リスクのある機能を無効にするには、待つことなく新しいビルドを待つ必要がない

生産性の高いルールはここで機能する。生産性の低い問題を逆転させることは高価なので、codeをフラグで送信する。

フラグを使用するチームは、UI条件付き部分に止まることが多い。 flag ? <NewUI /> : <OldUI /> しかし、それは見える部分だけであり、実際には興味深い部分ではない。フラグのコア価値は、リモート構成、決定論的ターゲット、機能を急いでシャットダウンできる能力である。これらは生産性で役に立つ。 Reactアプリがアプリ全体の実行時設定も必要な場合、Capacitorアプリ用のリモート設定プラグインも必要になるリリース管理モデルに合致する。

フラグは信頼されていない場合、役に立たなくなる。

フロントエンドのコードベースが成長するにつれて、同じ失敗パターンを観察しています。チームはフラグを迅速に追加し、環境間で名前がずれ、デフォルト値が設定ミスを隠し、誰もが「オン」がグローバルにオン、スタッフ用にオン、またはステージングでオンのみを意味するかを確かめられないようになります。その時点で、フラグシステムはリスクを減らすのではなく、リスクを生み出します。

型安全性は役立ちますが、問題の全体を解決するものではありません。チームは依然として明確なレジストリ、所有権、フラグを評価するための一貫した方法が必要です。そうしないと、Reactコンポーネントはロールアウト状態についてローカルな仮定を立て、ロールアウトや部分的なロールバック中にそれらの仮定が破綻することになります。

違いは簡単にわかります。

用途	弱いバージョン	強いバージョン
UI切替	コンポーネントのローカルブール値	所有権とロールアウトルールを持つリモートフラグ
リリース安全性	Manual deploy rollback	Immediate disable through remote configuration
Experimentation	Ad hoc branch comparison	Stable cohort assignment and measurable exposure

The important mindset shift is simple. React feature flags belong to your release process, not just your JSX. Treat them that way, especially in apps where shipping a new build is slow, and they become one of the few tools that reduce blast radius when production gets messy.

Architecting Feature Flags in Your React App

The architecture decision matters more than the first flag. If you wire flags directly into random components, you’ll get duplicated logic, loading flicker, and a codebase where nobody knows which source of truth to trust.

Use a runtime provider, not scattered conditionals

For React apps, the dependable approach is to treat flags as runtime data. Guidance for React flagging recommends three things: evaluate flags on the server or in a local SDK cache, persist cohort assignment deterministically, and render the final UI state before hydration or use anti-flicker protection so users don’t see the wrong default first (React フラグメソッド).

code の場所が変わる。アプリのルート近くにフラグのロードを配置する。消費を簡単にする。葉のコンポーネント内でフラグを取得しないようにする。

実用的な形は次のようになる。

メインツリーがレンダリングされる前にフラグをロードまたはハイドレートする。
プロバイダーを通じて公開する。
1 つのフックまたは 1 つのラッパーペターを通じて読み取る。
プレゼンテーショナルコンポーネントから評価ロジックを外す。

アプリ全体の設定やフラグのためのリモートコンフィグレイヤーが必要な場合は、 Capacitor リモートコンフィグプラグインハイブリッド React アプリで自然に合致する。

パターン 1: React Context とカスタムフック

このパターンはデフォルトです。一般に推奨します。明確でテストしやすく、後でベンダーを切り替える場合に簡単に移行できるからです。

import React, { createContext, useContext, useMemo } from 'react';

type FlagValue = boolean | 'control' | 'variant-a' | 'variant-b';

type Flags = {
  newCheckout: boolean;
  checkoutExperiment: FlagValue;
  deleteTaskEnabled: boolean;
};

const defaultFlags: Flags = {
  newCheckout: false,
  checkoutExperiment: 'control',
  deleteTaskEnabled: false,
};

const FeatureFlagContext = createContext<Flags>(defaultFlags);

export function FeatureFlagProvider({
  flags,
  children,
}: {
  flags: Flags;
  children: React.ReactNode;
}) {
  const value = useMemo(() => flags, [flags]);
  return (
    <FeatureFlagContext.Provider value={value}>
      {children}
    </FeatureFlagContext.Provider>
  );
}

export function useFeatureFlag<K extends keyof Flags>(key: K): Flags[K] {
  return useContext(FeatureFlagContext)[key];
}

使用は面白くない、そしてそれはあなたが望むものだ。

function DeleteTaskButton() {
  const enabled = useFeatureFlag('deleteTaskEnabled');

  if (!enabled) return null;
  return <button>Delete task</button>;
}

このパターンは、コンポーネントが最終的な答えだけを要求するため、うまく機能する。

2 番目のパターンは、より高階のコンポーネントを使用します。

高階のコンポーネント 高階のコンポーネントは、ルート要素、ルート要素、またはレガシークラスコンポーネントをすべてゲートする場合に便利です。 使用方法:

import React from 'react';
import { useFeatureFlag } from './FeatureFlagProvider';

export function withFeatureFlag<P>(
  flagKey: 'newCheckout' | 'deleteTaskEnabled',
  Fallback?: React.ComponentType<P>
) {
  return function wrap(Component: React.ComponentType<P>) {
    return function FeatureFlaggedComponent(props: P) {
      const enabled = useFeatureFlag(flagKey);

      if (!enabled) {
        return Fallback ? <Fallback {...props} /> : null;
      }

      return <Component {...props} />;
    };
  };
}

欠点は、間接性です。モダンな React では、ホックはトレースが簡単ですが、HOC は DevTools でコンポーネントツリーを混乱させる可能性があります。

const CheckoutPage = () => <div>New checkout</div>;
const LegacyCheckoutPage = () => <div>Legacy checkout</div>;

export default withFeatureFlag('newCheckout', LegacyCheckoutPage)(CheckoutPage);

コンポーネントはロールアウトポリシーを決定するのを許可しないでください。コンポーネントはフラグ結果を消費するだけで、バケット化、ユーザーターゲティング、キャッシュリフレッシュルールを実装する必要はありません。

React の機能フラグパターンを比較する

基準

コンテキスト + ホック	__CAPGO_KEEP_0__	高階コンポーネント (HOC)
__CAPGO_KEEP_0__	コンポーネントレベルの決定とバリアント	フルページ、ルート、またはレガシーコンポーネントをラッピング
柔軟性	高	中
開発者エクスペリエンス	モダン関数コンポーネントでは強い	フックが不便な場合に役立つ
バンドル明確性	明確なインポートと直接的な読み取り	木構造の抽象化
テスト	プロバイダーを通じて簡単にモックできます	ラッピングされた統合ケース用にラッパーが簡単です
長期的なメンテナンス	通常は良いでしょう	sparingly使用する場合、問題ありません

Reactの機能フラグを実装する場合は初めての場合は、まず コンテキスト+フック特定のラッパー式ゲーティングのためのラッパーを追加する必要がある場合にのみ

ロールアウトとロールバック戦略の実装

機能がリリース後に不調になると、UIは新しいボタンまたは画面を表示するだけかもしれませんが、決定するべきことは誰が最初にそれを見るか、露出の速度がどれくらいで、どれくらいの速度で停止できるか、再デプロイを待たずに停止できるかです。これは、モバイルまたはデスクトップのパッケージ内に配布されるReactアプリケーションでは、ロールバックがリモート設定に依存する可能性があるため、特にアプリストアのレビューまたはデスクトップ配布が時間がかかる場合に、さらに重要です。

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__ Math.random() __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__Optimizely サンプルサイズ計算機チェックがなければ、チームはノイズを信号と見なし、機能を早すぎて推進することがよくあります。

ブラウザ外の段階的な更新のための便利な参照は Capacitor ライブ更新の段階的なロールアウトパッケージされたシェル内で実行するReactアプリの場合も、バイナリロールバックが遅いため、同様のリリースディスクiplineが適用されます。

ターゲットリリースは、爆発半径を減らすことができます。

ユーザーをロックアウトする可能性のある機能は、ランダムなパーセンテージで始めるべきではありません。例えば、請求フロー、承認の求め、データの移行などです。

ターゲットリリースは、最初のアウディエンスが既知の特性で定義されている場合にうまく機能します。

内部スタッフのためのドッグフード
粗いエッジに同意したベータテスター
特定のアカウントの階層
法律または言語の要件が異なる地域
__CAPGO_KEEP_0__

Ring-based releaseは、より効果的なターゲット設定を可能にします。Ring 0は従業員、Ring 1は信頼できる外部テスターです。後続のリングでは、信頼性が向上するにつれて露出を拡大します。この構造は、リスクが明らかに不均等な場合に、すべてのユーザーを1つのプールとして扱う一般的な間違いを回避するのに役立ちます。

このリリースモデルとよく相性の良いエンビデッドウォークスルーはこちらです。

リスクフラグは、機能を即時停止できるフラグです。

リスクのある機能には、即時停止できるフラグが必要です。実際には、通常は、機能フローの全体を無効にするトップレベルの運用フラグが必要です。プレゼンテーショナルフラグは、バックグラウンドの要求、効果、ナビゲーションパスがまだ実行されている場合に、単にエントリポイントを非表示にするだけです。

リリース前に、リスクフラグを設計すること。

アプリ起動の早い段階で評価すること。
最後の安全な値をキャッシュすること。
フラグサービスが利用できない場合に、安全なデフォルト値を選択すること。
機能を無効にすることで、サイドエフェクトが止まることを確認すること。
インシデントの際にフラグを切り替えることができるユーザーをドキュメントすること。

Webアプリ向けには、リリースリスクを軽減します。モバイルおよびデスクトップのReactアプリ向けには、軽微なインシデントとユーザーが修正されたビルドを受け取るまでの待ち時間の差となります。codeがすでにバンドルに含まれている場合、リモートフラグはロールバック戦略の一部になります。

機能観測性のテストとフラグの負債管理

機能フラグの簡単な部分は、1つを追加することです。費用の高い部分は、多くのフラグが存在し、誰もそのうちどれがまだ重要であるかを覚えていないときに始まります。

現代のサーバールームの画像。サーバーラックと点滅する光と整理されたネットワークケーブルが並んでいます。

各フラグは、信頼できる状態の数を倍増させます。

マーティン・フォーウラーの警告はまだ有効です:機能フラグが存在すると、チームは両方の状態、「On」、「Off」を検証する必要があります。 On and Off マーティン・フォーウラーによる機能トグルに関する警告その結果、Reactアプリケーションに直接影響します:).

条件付きレンダリングパスは、迅速に広がります:

機能フラグの複雑さは、状態の組み合わせの数を指数関数的に増やします。 A single page can have multiple branches before anyone notices.
Hydration の不一致が触発されるようになります: クライアントとサーバーは評価が間違ったタイミングで行われる場合に異なる意見を持ちます。
スナップショットテストは単独ではあまり役に立ちません: ハッピーパスレンダリングでは、反対のフラグ状態がテストされていない場合、ほとんどの情報は得られません。

実用的テストスタックは次のようになります:

評価ロジックのユニットテストを行ってください。
コンポーネントテストでキーフラグされたbranchをテストしてください。
エンドツーエンドのカバレッジを追加して、リスクのあるパスのみをテストしてください。
デフォルトのフォールバックを明示的に検証してください。

すべての組み合わせを目指すのではなく、ユーザーに害を及ぼすかレイアウトを破壊する可能性のある状態をテストしてください。

フラグの負債は実際に存在し、静かに高額の費用を生み出します。

古い旗はcodeの腐敗の形をとる。条件分岐、コメント、ダッシュボード、ランブックに残る。すると、誰かが「一時的な」ブランチを数ヶ月後に編集する。誰もがそれを削除しなかったからだ。

実践で機能するクリーンアップルールは簡単である。

問題	何をするか
所有者がいない	旗が作成されたときにチームまたは人を割り当てる
終了状態がない	旗が削除、保持、またはconfigに変換されるかどうかを決定する
旗が制御するのは多すぎる	旗を小さく、狭い旗に分割する
旗の背後にあるコアロジックが隠れている	ビジネスロジックをレンダリング条件分岐から外す

Cleanup rule: 1日以内にフラグは所有者、目的、削除計画を持つべきです。

チームは「信頼」問題に陥ることがあります。フラグ名は存在しますが、フォールバックが間違っています。ダッシュボードのエントリが変更されたが、アプリタイプは変わりませんでした。codeパスは死んでいるが、まだアクセス可能です。なぜなら、型生成とレジストリ検証は大規模システムでは重要だからです。初期実装が簡単に見えたとしても。

観測性は、フラグが機能したか、ただ存在したかを教えてくれます。

ロールアウトは、フラグが完全に露出した時点で完了したと考えるのではなく、チームが何が起こったかを知る時点で完了したと考えるべきです。

少なくとも次の質問を追跡するべきです:

露出: どのユーザーがどのバリアントを見たか?
エラー: フラグされたパスがクライアントサイドのエラーを引き起こしたか?
採用: ユーザーが公開された機能を使用したか?
ロールバック信号： 何の閾値がオフにするのに役立ちますか？

リリースレビュー中、旗の変更についてはまだ推測することになります。

CI/CDを使用した旗のセキュリティと自動化

悪いデプロイは明らかです。悪い旗の変更は、デプロイと同じレビュー経路を通らなくても、生産動作を変更するため、より危険です。codeのパスが実行されるかどうか、ユーザーが受け取るものが変わるなど、デプロイアクセスと同じ規制が必要です。

旗はリリースの制御です。旗を生産で切り替えることができるチームは、ユーザーが受け取るもの、実行される__CAPGO_KEEP_0__のパス、そして時々はどの統合が発火するかを変更できます。デプロイアクセスと同じ規制が必要です。

Feature flags are release controls. If a team can flip a flag in production, that team can change what users get, what code paths run, and sometimes which integrations fire. That deserves the same discipline as deploy access.

ロールベースのアクセス制御：

旗の変更を生産で行うことができる人を制限し、読み取りアクセスと編集アクセスを分離する。 監査ログ：
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__の変更履歴を明確に記録する。変更者、変更時刻、変更した環境を記録する。
環境隔離: テスト変更が実稼働トラフィックに影響しないように、ステージング、プレビュー、実稼働のフラグを区別する。
機密情報の決定に影響を与えるサーバーサイドチェック: クライアントフラグはUIを隠すことができるが、請求アクセス、特典、認可には影響を与えるべきではない。

フラグダッシュボードを共有スプレッドシートのように扱うのはよくない。製品は顧客に機能を有効にする。サポートは不満を止めるために機能を無効にする。エンジニアはデプロイがないので機能が変更されていないと考えている。そうした設定は、インシデントを説明する必要があるまで機能する。

バンドルアプリはリスクを高める。Webアプリではcodeの修正が迅速に配信できる。Capacitorまたはデスクトップアプリでは、既にcodeの破損がデバイスに待ち受けている可能性がある。codeでReactモバイルアプリを構築するチームは、承認ルールに厳格であるべきで、ロールバックは機能を無効にするのではなく、バイナリを置き換えるのではなくなるからだ。 React mobile apps with Capacitor フラグが外部に存在する場合、信頼性が低くなる。同様のワークフローで機能を配信するプロセスの中で管理するのが安全なパターンだ。通常は、次のことを意味する。

__CAPGO_KEEP_1__

__CAPGO_KEEP_2__

__CAPGO_KEEP_0__

機能codeの同一PRで旗を生成または更新する
CI中でリモートレジストリと型付き旗定義を検証する
環境ごとにデフォルト値を意図的に設定する
旗が欠落または不正設定の場合、リリースをブロックする
期限切れの旗またはロールアウトの終了状態を持つ旗のクリーンアップタスクをスケジュールする

生産停止の原因となる可能性のある旗のセットアップをCIで検出できるようにするという単純なルールを好みます。そうすることで、リリース前に欠落したデフォルト値、キー名の変更、古い環境マッピング、codeに存在するがコントロールプレーンに存在しない旗を検出できます。

パイプライン構造のスターティングポイントが必要な場合 Git Action CI/CDワークフローのビルドチェック、デプロイゲート、旗検証のための拡張可能な自動ステップのための良い参照です。

秘密とSDKの選択肢を面白くする

フロントエンドチームは旗のセキュリティを過度に複雑にし、明らかな部分を無視することがあります。ブラウザで設計された一般的なSDKキーは、クライアントサイドで評価することができます。管理用トークン、書き込み用クレデンシャル、環境管理用キーはCIまたはバックエンドサービスのみに属するものです。

実用的には単純です。プレゼンテーション変更や低リスクの実験にはクライアントサイド評価を使用し、価格、許可、敏感なフローのキルSwitch、ローカルJavaScriptに信頼できないものはサーバーサイド評価を使用します。

スローページング環境では、リリース速度が遅い場合に限り、境界はより重要になります。 Web チームは、迅速なデプロイで回復できます。一方、モバイルとデスクトップチームは、フラグシステムを回復メカニズムとして使用する必要があります。ただし、不正な人がプロダクションフラグを編集できる場合、またはCIがフラグ契約を検証しない場合、ロールバックは迅速に混乱することになります。

Beyond the Web Feature Flags for Capacitor and Mobile Apps

React機能フラグのほとんどの記事は、即座に再デプロイできるWebアプリを前提としています。その仮定は、Reactがcode内に住んでいる瞬間から破壊されます。 Capacitor, Electron、または別のバンドル実行環境。

バンドルアプリはリリースの計算を変える

ハイブリッドアプリでは、ユーザーがすぐに更新しない限り、JavaScript、CSS、アセット、設定を含むパッケージをユーザーに配布します。そのアプリケーションは、ユーザーがそれを使用したいと考えている前に、すでにデバイスにインストールされている可能性があります。これはフラグの役割を完全に変えることになります。

最近のハイブリッドリリース戦略に関する議論では、すでに存在するReactフラグのコンテンツが、CapacitorまたはElectronアプリ用のリリースリスクモデルを扱っていないことが指摘されました。そのチームにとって、主なニーズは、フラグ、ターゲットチャンネル、ロールバック保護を組み合わせたリリースオーケストレーションレイヤーです。ただし、ストアのレビュー遅延を回避することが重要な場合、単純なオン/オフスイッチではありません。ハイブリッドアプリリリースリスクに関する議論).

正解です。バンドルアプリでは、フラグは条件付きレンダリングではなく、すでに配布された機能を遠隔で有効にすることに関係しています。 すでに配布された機能を遠隔で有効にする.

モバイルまたはデスクトップのReactアプリでは、フラグはUIの表示よりもリリースタイミングを制御することが多い。

This is also why channel-based distribution matters. If you’re building hybrid apps and need the app shell plus web code release model to make sense together, creating React mobile apps with Capacitor Reactモバイルアプリを作成することは、実用的でない始め方である。

フラグは、更新配信と組み合わせることで最も効果が高い。

For mobile and desktop teams, flags alone won’t solve every release problem. They can hide or enable code paths, but they can’t replace shipping fixed assets or logic when the bug is already in the bundle.

フラグは、パスを非表示または有効にすることができるが、既にバンドルに含まれているバグに対処するために固定アセットやロジックを配信することはできない。

deliver code updates outside full store cycles when your platform allows it,
プラットフォームが許可する場合、フルストアサイクル外で__CAPGO_KEEP_0__更新を配信することである。
更新をチャネルまたはアウディエンスにターゲットすることである。

フラグを使用して、有効化、ロールバック、ステージドエクスポージャーを制御することである。

If your team ships Capacitor or Electron apps and needs that release-control layer, Capgo Cloudflareを利用することは、1 つのオプションです。これは、特定のチャネルに署名されたWebバンドルを配信し、ロールバック保護と観察性をサポートし、機能フラグがライブ更新と共に機能する必要があるハイブリッドアプリのワークフローに適合します。

React機能フラグ: 完全な実装ガイド

あなたが React機能フラグ: 完全な実装ガイド を使用してチャネルルーティングとステージドロールアウトを計画する場合、チャネルでチャネルルーティングとステージドロールアウトの実装詳細を参照してください。チャネルでチャネルルーティングとステージドロールアウトの実装詳細を参照してください。チャネルでチャネルルーティングとステージドロールアウトの実装詳細を参照してください。ベータテストソリューションベータテストソリューションにおける製品ワークフローについて、バージョンターゲットソリューションバージョンターゲットソリューションにおける製品ワークフローについて、

React Feature Flags: A Complete Implementation Guide

Table of Contents

モダンなReactアプリのための機能フラグの重要性

デプロイとリリースは異なる仕事です

フラグは信頼されていない場合、役に立たなくなる。

Architecting Feature Flags in Your React App

Use a runtime provider, not scattered conditionals

パターン 1: React Context とカスタム フック

2 番目のパターンは、より高階のコンポーネントを使用します。

基準

ロールアウトとロールバック戦略の実装

__CAPGO_KEEP_0__

ターゲットリリースは、爆発半径を減らすことができます。

リスクフラグは、機能を即時停止できるフラグです。

機能観測性のテストとフラグの負債管理

各フラグは、信頼できる状態の数を倍増させます。

フラグの負債は実際に存在し、静かに高額の費用を生み出します。

観測性は、フラグが機能したか、ただ存在したかを教えてくれます。

CI/CDを使用した旗のセキュリティと自動化

__CAPGO_KEEP_1__

秘密とSDKの選択肢を面白くする

Beyond the Web Feature Flags for Capacitor and Mobile Apps

バンドルアプリはリリースの計算を変える

フラグは、更新配信と組み合わせることで最も効果が高い。

React機能フラグ: 完全な実装ガイド

パターン 1: React Context とカスタムフック