フロントエンドを考える 〜概念編〜

この記事のシリーズでは私がフロントエンドに関して思っていることを徒然に語っていこうと思います。
ちょっと長くなり過ぎそうなので以下の4つに分けて書いていこうと思います。

1.概念的な話 - フロントエンドアプリケーションとは何でできているか

フロントエンドアプリケーションを保守性とユーザへの価値提供を両立して開発するために、アプリケーションを抽象化して、いい感じの設計をする必要があります。

これの土台作りをするために概念としてフロントエンドアプリケーションとは何なのかを考えていきます。

2.技術的な話 - フロントエンドアプリケーションはどのように実行されるか

Webフロントエンドはブラウザで実行され、表示のためには HTML, CSS, JS が必要です。当たり前のことではありますが、実際に開発を進めていく上では概念だけでなく、実際に動く How の部分を知る必要があります。

これらの要素技術を見ていって、更にそれを我々開発者が扱いやすいようにするためにどのような拡張が行われているかを考えます。(というのを書こうと思っていましたが、そこまで面白い観点になりそうもないので書かないかもしれません)

3.目的的な話 - フロントエンドアプリケーションは何のためにあるか

なぜ "Web" で "フロントエンド" と呼ばれる UI を提供するのか、ざっくり言うと私は「ユーザがシステムを介して達成したいゴールを達成しやすくするため」だと考えています。

「誰のために、何のために」を深ぼることによって、デザイン、アクセシビリティ、パフォーマンスなどフロントエンドエンジニアに求められる非機能の部分について触れていきたいと思います。

4.プロセス的な話 - フロントエンドアプリケーションはどのように作られるか

最後にユーザを開発者、デザイナーなどの作り手と捉えた時のフロントエンドアプリケーションについて考えてみます。

フロントエンドはデザインとの接合も必要ですし、バックエンドとの繋ぎ込みも行います。そう言った隣接する領域への理解の話と、フロントエンド自体の開発プロセスの改善についても考えていきます。

概念的な話 - フロントエンドアプリケーションとは何でできているか

結論から述べると私はフロントエンドをこの二つの図で表現できると思っています。

これだけ出されても謎だと思うので順を追って解説していきます。

まず我々が作るソフトウェアにはシステムとユーザがいます。

このままでは何も起こらないので、ユーザとシステムが交信できるもの、要するに UI が必要です。

UIでは、まずシステムが最初の画面を表示します。

これをユーザが目なり耳なりでインプットとして受け取り解釈します。その解釈の結果ユーザが アクション を起こします。

このアクションはシステムにとって解釈可能なインプットとなり、このインプットを受け取ったシステムでは 状態 が変わります。そしてこの 状態 が変わった結果、次の新しい画面を生成します。

大雑把ですがこの

画面の表示 → ユーザのアクション → 状態の変化 → 画面の表示...

のループがグルグル回っていくものを実装するのがフロントエンドなんじゃないかと私は考えています。

そしてこれをプログラミングするために落として考えると大きい登場人物は次のようになります。

(画面の表示 -> View, ユーザのアクション -> Action, 状態 -> State)

一個一個具体的に考えていこうと思います。

State

アプリケーションの状態を表します。個人的には大きく以下のようなモノに分類されるのではないかと思います。これらがどのくらいあって、 View や Action の関係性の複雑度がどうなっているかによって設計の仕方だったり選択するライブラリが変わってくるのだと思います。

• Model state
  • バックエンドからとってきたデータのキャッシュ
• UI state
  • モーダルの開閉、トグルボタンのオンオフなどUIに関わる状態
• Auth state
  • 認証情報に関わる状態
• Location state
  • 現在ユーザいるページや、遷移したページの履歴などの状態
• Communication state
  • 外部APIなどと通信している時の状態

View

ユーザが情報をインプットするため & システムに対して Action を起こすための見た目の部分です。

Action

ボタンをクリックする、ドラッグ&ドロップなどの、ユーザがインターフェイスに対して実行する動作を表します。
(※ ただし、ページ表示時にリクエスト飛ばしたり定期的にポーリングや Web Socket で受け取るなどユーザ自身が起因でない Action も色々あります)

これをどう実装に活かすか

正直実務にガッツリ活きるかと問われると自信ないのですが、なぜこんなにもフロントの世界はライブラリが溢れているのかを理解するためや、状態管理の仕方を考える時に全体感を掴むことは悪くないのではないかと思います。

例えば、この State -> View -> Action というフレームを意識していれば、自分のアプリケーションに照らし合わせて次のようなことを考えて行くと最適な書き方が見えてくるのではないかと思います。

• どんな State や Action が発生しそうか
• State と View 、View と Action、 Action と State の関係性はどうなっているのか

おわりに

以上、私が思うフロントエンドアプリケーションとは概念的にはこういうものなんじゃないかというのを書いてみました。

次の記事では実際にアプリケーションが機能するために必要な "技術" について考えていきます。