📝

LaunchDarklyのstorybook addonを作ってフラグによるUI変更のメンテナンス性をあげたい話

2022/02/11に公開

React

Storybook

LaunchDarkly

tech

はじめに

https://launchdarkly.com/

LaunchDarklyというSaasがあり、feature flagをダッシュボードやsdkによって管理、実装しやすくしてくれるものです。

サービスに関しては、既存の記事があるので以下を参考にすると良いと思います。

導入の話はこちら

運用イメージはこちら

課題

feature flagと一括りに言っても様々な使い方がありますが、特にマルチテナント毎での機能On/Offなど、長期的に仕様として存続し、それによってUIが微妙に変化するような使い方をしたいケースがあります。

各機能毎に微妙に違うコンポーネントを作っておきそれに対して、テスト/確認するのは簡単でも、共通で持ちたい機能の変更/メンテナンスにコストがかかってきます。

なので一つのコンポーネントの中で変更必要なところだけフラグが適用されるようにしたいです。ですが、変更によって今見ているのと違うフラグの状態時まで影響を与えてしまったりすることがあります。これを開発/レビュー時に毎度気をつけるのは骨が折れますし、絶対にいつか漏れが生じます。

よって、フラグの状態を再現でき、万が一影響を与えてしまったときに自動的に検知できる状態を手軽に作れるようにしたいです。

作ったもの

これを使用すると、以下のように各story毎にflagの状態を指定でき、簡単にflagの使用状態に応じたstoryを作成可能になります。

import Example from '.';

export default {
  component: Example,
} as ComponentMeta<typeof Example>;

// フラグ一つで使用する場合
export const FlagActive: StoryObj = {
  parameters: {
    launchdarkly: {
      flags: {
        testFlag: true,
      },
    },
  },
};

// 複数のフラグを組み合わせて表現したい状態がある場合
export const TestMode: StoryObj = {
  parameters: {
    launchdarkly: {
      flags: {
        firstFlag: true,
        secondFlag: false,
        thirdFlag: false,
      },
    },
  },
};

これをstorybookで見ようとすると、たとえば以下のようになります。

TestMode という条件で、

コンポーネントの使い方は何通りあるか
どのフラグをどの状態で使用しているか
UIがどういう状態であるか

が一目でわかるようになります。

storyの名前をフラグの状態や受け入れ基準と一致させることによって、エンジニア以外のメンバー(ドメインエキスパートやデザイナー)の確認しやすさにもなります。

最後に

以上でフラグを用いた、storyの作成が簡単にできるようになりました。
これに追加して、作るstoryをinteractive storyにしたり、storyに対してvisual regression testを組むことによって、新規にコンポーネントを作るときに受け入れ条件に従ってパターンを登録しておくだけで、リファクタ/受け入れ条件追加/変更時の品質担保が可能になります。

その話はこちら↓

また、PR単位でstorybookを確認できるようにしておけば、レビュワーがダッシュボードで実際にフラグを切り替えるなどの操作もなく適切なUIパターンになっているかが確認できます。

以上、フロントテストライフのために初めて、storybookのaddonを作ってみた話でした。

はじめに

課題

作ったもの

最後に

Discussion