デザイナーのための！コンポーネントデザインに必要なエンジニアリングの仕組み

こんにちはフロントエンドエンジニアの峯です。
デザイナーの皆さん、アプリのUIやWebサービスのデザインを行う際、どのようなことを意識してデザインされていますでしょうか？

以前までの、Webページをデザインするという考え方から、昨今ではデザインされたコンポーネントの組み合わせによってページを構成するという考え方に変化してきました。

この考え方の変化によって、ユーザーの操作に対してしっかり状態を示すことが可能になりました。

ユーザーに対してしっかり状態を示すためには、コンポーネントが受け取るユーザーの操作に対する状態を網羅する必要があります。（次の章で具体的なイメージを解説します。）

デザイナーがエンジニアリングの仕組みを知ってデザインすることで、以下２点が得られるのではないかと思います。

1. コンポーネントデザインやデザインシステムを作るヒントになる
2. エンジニアとコンポーネント設計の認識が揃い、開発速度の向上や、ユーザーへのリッチなインタラクション表現による操作感アップに繋がる

この記事では、事例を交えながらコンポーネントデザインに関するエンジニアリングの仕組みの変化や知識を紹介します。

SPA（シングルページアプリケーション）によって生まれた変化

SPAとは、ページ遷移を行う事なく単一のページ上でコンポーネントの組み合わせによってページを構成する開発手法です。

単一ページ内で、複数のコンポーネントを表示したり、しなかったり、コンポーネントの状態を変化させたりすることでさまざまな画面をレイアウトします。

つまり、それぞれコンポーネントが独立しているため、ページを切り替えなくてもコンポーネント単位で、対象のみの状態変化を実現することができます。それによって、よりユーザーの小さなインタラクション表現を可能にしています。

上記の図のように、マルチページアプリケーション（以下、MPA）はcontact.htmlというデータ送信前の状態からcomplete.htmlというデータ送信後の状態にページを切り替えることで実現しています。

SPAの場合は、ページはずっとindex.htmlのままで、コンポーネントの状態変化を行い、入力フォームを送信完了メッセージに、ボタンを非表示にすることによって状態の切り替えを実現しています。

どのような画面があるかではなく、どのようなコンポーネントの状態が存在するかを考えます。

例えば、問い合わせフォームで利用する入力フィールドは、以下の図のような状態別のUI表現を持ちます。これらはページ遷移を行うことなく、ユーザーがフォーカスしたり、ボタンをクリックするなどのアクションによって入力フィールド単体で状態を変更することができます。

上記の入力フィールドにかかわらず、全てのコンポーネントはそれぞれ状態別の表現を持っています。また、ページ上に複数存在して、それぞれで状態を管理します。

SPA開発の代表的な技術として、JavaScriptフレームワークの「React」や「Vue.js」があります。

この後の章で、これまでの開発手法である、複数のページで構成されるMPAとSPAがどのように異なっているのか、また、SPAが可能にしたUI表現を画面の例を交えて詳しく紹介します。

次の章で、問い合わせフォームUIを例にMPAとSPAの考え方の違いを説明していきます。

MPAの問い合わせフォームUI

MPAはページの遷移によって状態が制御されます。
問い合わせフォームの主な状態は「送信前」、「送信後」の２つの状態が考えられます。

※送信内容確認画面は一旦ここでは考えません。

送信前
ユーザーが送信情報を入力して、「送信ボタン」をクリックするまでの状態です。

送信後
ユーザーが「送信ボタン」をクリックして、データがデータベースに送信され、送信が完了した状態です。

SPAの問い合わせフォームUI

SPAの場合は、ユーザーからのアクションを受け取るインターフェースの「ボタン」コンポーネントに着目します。

ボタンコンポーネントの想定される状態は、「送信前」、「送信中」、「送信後」の３つの状態が考えられます。

送信前
ユーザーが送信情報を入力して、「送信ボタン」をクリックするまでの状態です。

送信中
ユーザーが送信ボタンをクリックして、データがデータベースに送信され、データベースから送信完了のレスポンスが返ってくるまでの状態です。

送信後
データベースから送信完了のレスポンスが返ってきた時の状態です。

SPAはページ遷移を行う必要がなく、コンポーネント単位でデータベースとの通信を行うことが可能なため、より小さなユーザーインタラクションをキャッチすることができます。

以下の図は、それぞれのコンポーネントが状態に応じて変化するUIを表しています。

ボタンコンポーネントのみではなく、テキストフィールドも状態が変更されていることがわかります。

このようにコンポーネント別に状態を定義して、ページのレイアウトを変化させるのが、SPAの特徴です。これにより、ユーザー操作に対してあらゆるパターンの表現が容易になりました。

誤解がないように説明すると、もちろんMPAの場合でも送信中の状態を持たせることは可能です。

エンジニアリングの仕組み

Reactで開発する場合に、どのようにコンポーネント単位の状態を管理しているのか説明します。

Reactは常にコンポーネントの状態（コンポーネントの状態 = State）を監視しており、ユーザーのアクションや、データベースからのレスポンスなどのイベント（コンポーネントのイベント = Action）によって、コンポーネントの状態を変更してUIを変化（表示 = View）させています。

以下の図のようなフローを、それぞれのコンポーネントが持つことによって、イベントに応じてそれぞれのコンポーネントがUIを変化させているのです。

1. クリックイベントが発生するとActionがイベントを処理（Action）
2. 処理に応じてStateを設定（State）
3. 設定されたStateを表現するUIを表示（View）

SPA開発では、コンポーネント別にイベントや状態を定義しています。

具体的な例

ここまでで、SPA、MPAの仕組みの違い、SPAを実現するエンジニアリングの仕組みを説明させていただきました。

ここまでの内容を踏まえて、実際にReactで開発されているPinterestのUIを見てみましょう。

以下のムービーは、Web版のピン作成画面です。ヘッダー部分に注目してください。

ピンが選択されるというActionの発生によって、ヘッダー内の要素のStateが変更され、Viewされる要素が変更されます。この時、ページ遷移は行われず、シームレスに表示の切り替えが行われていることがわかるかと思います。

この例では、編集中のピンが表示されている状態、編集中のピンが選択されている状態によって、ヘッダーの状態、編集中のピンの状態、ピン追加ボタン（左側の＋ボタン）の状態がそれぞれ変更されています。

このように、ユーザーのアクションによってさまざまな制御やインタラクションなど、状態別の表現が可能になっています。

さいごに

コンポーネントが自立可能となったことで、表現方法も多様化してきていますし、どれだけコンポーネントの状態や性質を定義するかでプロダクトのこだわりやクオリティに差がつきやすくなっています。

今後も変化が止まることはないですし、エンジニアとしてプロダクトを実現する役割として、ユーザーにとって親しみやすい インターフェースを作っていきたいなと思います。
そして、また新たな技術が現れた際にはその仕組みを伝えていければと思います。

プロダクト開発を行う皆さんにとって、こだわりのプロダクト開発の参考になれば幸いです。