フロントエンドの設計から実装までした時に考えたことやコードをまとめていく。
今回は設計思想について
デザインパターンはFluxを使っていますが、基本的な思想部分はどのデザインパターンでも変わらないと思います。
GitHub→angular_flux_study(まだ研究中)
前提知識として読んでおいて欲しい記事→エンジニア視点から見るWebサービスの全体像
設計したものを誰が使うのか
以前書いた記事
WebAPIの設計から実装まで〜設計編〜
WebAPIの設計から実装まで〜実装編〜
では、設計したものを使う人は「サーバーサイドエンジニア」のみだったのでただただ拡張性や安全性を意識すればいいだけだったのだが、フロントエンドにおいては様々な人が開発に携わるので話が違ってくる。誰がどんな目的で開発に携わるのかを以下にまとめてみた（筆者の想像だが）。
- デザイナー、マークアップエンジニア
HTML,CSSなどブラウザに表示される部分(View)のコードを書く。動きをつけるためにjQueryなどjavascriptのライブラリを少々使う。
- フロントエンドエンジニア
javascriptなどでロジック部分を書く。具体的には、Ajaxなどを用いてWebAPIを叩いたり、Routingを制御したり、キーボード制御をしたり、Viewにデータを渡したりする。パフォーマンスのチューニングもフロントエンドエンジニアの仕事だろう。
- 企画マーケティングなどの非エンジニア
「ここの文字を大きくしたい」や「この画像を少し小さくしたい」といった細かいデザインの修正をデザイナーに頼まずに自分で修正したい人
ここで何が言いたかったかというと、「全員が全員プログラミングに対しての知識があるわけではない」ということだ。
非エンジニアでもなるべく楽に環境構築できるように努力する
「WebAPIを構築して、フロントエンドを構築してようやく開発環境が整う」といった状態だとエンジニアならサクサクできるのでいいのだが、非エンジニアにとっては非常に難易度の高い問題になってくるだろう。そのようなつまらないことで貴重な時間を奪うのはもったいない。擬似WebAPIを構築してWebAPIの構築時間を減らしたり、一通りのパッケージを自動でインストールできるようにスクリプトを書いたりして、全体の労力を最小限にする努力をするべきだ。
ファイル分割をきちんとする
ファイル分割することは非常に大事だ。その理由はたくさんあるが、以下の理由が挙げられるだろう
- 見通しが良くなるため、ソースコードのデバッグが楽になる
- 機能拡張がしやすい
- どこに何があるか把握しやすくなる
- 非エンジニアが自分がどのファイルをいじればよいかわかりやすくなる
- コンフリクトが起こりにくくなる
コンフリクトが起こりにくくなるという点について説明すると、ファイル分割をやらないと複数人で同じファイルを弄るケースが多くなってしまうからだ。ソースはGitで管理することが予想されるが、いちいちfetchしてmergeしてコマンド叩いて・・・・という作業をしなければならない。これは非エンジニアには非常に負担になるだろう。
フロントエンドのデータフロー
下図のように設計した
フローを説明すると、
-
ViewでUserからの動作を受けるとその動作に対してのActionが呼ばれる -
ActionはDispatcherにeventとパラメータを渡す -
DispatcherにはあらかじめeventとそのcallbackのStoreの処理を保存しておく -
StoreではWebAPIとの通信を主にし、その結果をViewに投げる
具体的なことは実装編で書きます。
FLUXについてもっと知りたかったら以下のサイトを見ると理解が深まると思う。
GitHub(facebook/flux)
Hacker Way: Rethinking Web App Development at Facebook(youtube)
FLUXを選んだ理由
フロントエンドはサーバーサイドより遥かにテストしにくいという欠点がある中で、どうやったらデバッグが楽になるかということを考えたときに、それぞれの処理を単純明快にすることが一番の近道だと思う。FLUXは「データが一方向に流れる」と言ったデザインパターンだ。FLUXを使うことによってどの処理でどのようにバグが出たのかということを特定するのが簡単になる。
また、Viewとロジックを切り分けることができるので非プログラマとの連携が取りやすくなると思う。
最後に
試行錯誤して学んだ知識なので間違いがあるかもしれないし、さらに良い設計方法もあるかもしれません。
コメントで批判していただけると嬉しいです。