- 何らかのプログラム言語で書かれたサーバーサイドMVCからSPAを使ったフロントエンドの環境へ開発環境を整える
フロントエンドへの機能的期待値が上がっている
- 画面遷移のレンダリングコストの削減
- APIにすることで BE−FEの責務分離
- BE−FE リリースサイクルを非同期
- バリデーション
- UIのコンポーネント化
- Testing Trophyによる堅牢なWebアプリケーション
- デザイン-FEの連携強化
- サーバーサイド viewから HTMLをはがす
- バックエンドのレンダリングHTMLからフロントエンドへviewを持ってくる
- このとき バックエンドのロジックがからむデータについては view IFを定義して渡すデータを資料化する
-
共通パーツをコンポーネント化
-
追加・更新・削除 viewのAPI化
-
SPA URLの発行
-
4.以降は バックエンドの作業がいくつか発生する
初期リリースからリリース優先で行っていた開発の1, 2年の現場では、 複雑化したロジックが堆積するものだ。
しかし、そのコードはお金を稼ぐロジック。 そこを柔軟にほぐしていく第一歩が サーバーサイドviewからHTMLをはがすである。
ここで目指すのは BE管理のHTMLからviewを切り離すことを目的とする。 そのため、難しいことはしない。 viewに書かれたHTMLを ページComponentに貼り付ける。 viewに書かれたJSをvueでいうmountedへ、reactでいうcomponentDidMountへ貼り付ける。 CSSは styled-componentやscoped cssへ貼り付ける。
このときサーバーサイドが直接テキストや数値はサーバーサイドviewのscriptタグ内に記述する。 FE側で参照している変数が明示的にわかるため、ドキュメント化するチャンスでもある。 それを資料化し、viewのIFとして定義すると今後のBE-FEの叩きにすると良い。
ここでは共通のパーツを定義することでコンポーネント指向に近づくための一歩である。
共通のパーツの定義はAtomic designでいうところのatomの定義を指す。
ページ単位で全て印刷しページごとに一意の番号をふる
広い場所にコピーを並べる
ページに含まれるコンポーネントに全て付箋を貼る
同じコンポーネントをグループ化しつつ別の場所(ホワイトボードなど)にまとめる
2枚以上のグループ化されたコンポーネントがあればそれをピックアップする
ピックアップされたものは atomもしくは moleculeになるので名前をつける
storybookやcodesandboxなどのツールを使ってatom/moleculeをデザイナーに見える形で作成する
次にview表示以降のform送信をAPI化していく IFについてAPI化したことによるセキュリティ周りの変更以外は既存のままでOK。
- 状態をFlux or Page コンポーネントに持たせる