PLAY DEVELOPERS BLOG

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

UI とロジックを分離することで UI パーツの再利用性と開発効率を改善できた話

こんにちは。プラットフォーム技術部開発第3グループの荒川です。プロダクトの「PLAY VIDEO STORES」の開発をしています。

フロントエンドの開発をしている際、デザインを確認するために特定の操作を行わなければならなかったり、コードを変更したりしなければならない場合があります。 これらの課題を解決するためにStorybookの導入とUIコンポーネントの分離をしました。今回は、そのプロセスと利点についてご紹介します。

課題

たとえば一般的なECサイトの商品購入確認画面は、以下のような手順で前提条件を満たさないと遷移できません。しかし、開発中のデザイン確認・検証の度にこの手順を踏むのは非効率です。

商品購入確認画面に進む
┗ 会員ログイン中である
 ┗ 会員登録する
  ┗ メールやOAuthなどで認証済
 ┗ ログイン処理をする
┗ 購入する商品が決まっている
 ┗ 商品を選んでカートに入れている
etc...

こうした状況を改善するために、多くの開発チームがStorybookのようなツールを導入しています。Storybookを使うことで、デザインの確認を独立して行うことができ、特定の操作を繰り返す必要がなくなります。

また、今回のプロジェクトでは、複数の環境で共通のデザインを使用したいという要件もありました。そのため、UIコンポーネントをnpmパッケージとして公開し、他のリポジトリからも利用できるように設計しています。

Storybookとは

Storybookとは、UIコンポーネントごとにプレビューを行うための「UIカタログ」ツールです。Storybookを使うことで、特定のコンポーネントを表示する専用のページを作成する必要がなくなります。開発者は各コンポーネントの引数や状態を視覚的に変更し、異なる条件下での動作を確認しながら実装を進めることができます。

Storybookの最大の利点は、UIコンポーネントの分離と再利用性の向上です。デザイナーや開発者が迅速にフィードバックを行い、各コンポーネントの設計や機能を検証することが可能になります。

1つのコンポーネントごとにプレビューすることができます。

また、コンポーネントに対して特定の値を渡した時にどう表示されるかも確認することが可能です。

storybook.js.org

デザインとロジックを分離する

Storybookを導入するだけであれば、既存のプロジェクトにStorybookをインストールし、storiesファイルを作成するだけですが、今回はUIコンポーネントの作成からロジック側での使用までを考えてみます。

Storybookを使ってUIコンポーネントを作成する

まず、プロジェクトにStorybookをインストールします。これにより、各コンポーネントのプレビュー環境が整います。Storybookでは、各コンポーネントを独立してプレビューできるため、デザインの変更やバグの発見が迅速に行えます。

インストール後、Storybook用に個別のストーリーファイル(例: Button.stories.js)を作成し、コンポーネントのバリエーションや状態を定義します。このストーリーファイルを使って、コンポーネントのさまざまな見た目や振る舞いを確認することができます。

UIコンポーネントをパッケージとして公開する

Storybookでコンポーネントを十分に検証したら、それらをnpmパッケージとして公開します。これにより、他のプロジェクトやチームが同じコンポーネントを再利用できるようになります。以下は、パッケージ化の手順です:

  1. package.json ファイルを設定し、公開するコンポーネントと依存関係を定義します。
  2. コンポーネントをビルドし、npmリポジトリに公開します。

ロジック側のリポジトリで使用する

UIコンポーネントをパッケージとして公開したら、それを別のプロジェクトでインストールして利用することができます。

インストール後、各プロジェクトで共通のデザインを統一して利用できるようになります。

導入して気づいたこと

実際にロジックとUIコンポーネントを別々のリポジトリに分離した結果、いくつかの利点と課題が見えてきました。

まず、新しい画面を作成する際、ロジックとUIが独立しているため、デザイン確認や変更が迅速に行えます。 UIコンポーネントを作ってからそれらを用いてロジックを持った機能を作るといった構造的なものは確定したものから実装という流れが実現できます。

しかし、デザイン側の変更が必要な場合、以下の手順を踏む必要があります。

  1. UIコンポーネント側で修正
  2. ビルドとパッケージ公開
  3. ロジック側にインストール

これらの手順を踏まなければならないため、ロジックとデザインを行き来する修正が頻繁に発生すると、若干の手間がかかります。こうした課題は、デザインとロジックの責務を明確に分け、各修正がどちらに属するかを慎重に判断することで解消できるかと思います。

最後に

ロジックとUI実装をリポジトリごとに分離することで、UIパーツの再利用性が高まり、開発効率が向上しました。

今後も、デザインとロジックの分離を進め、より良いプロダクト開発を目指していきます。

最後までご覧いただきありがとうございました。