マイクロフロントエンド(SPA)
-
SPA
-
フロントエンドとバックエンドを切り離す「マイクロサービス」の考えに乗っ取る
-
従来のHTMLを静的に返す(+AJAX)形はどちらも結合されている
-
SPAを勧めていくとフロントエンド層が肥大化(モノリシック)になり管理が難しくなる
-
マイクロフロントエンド
-
ページを独立したチームによって管理する機能の集合体と捉える
-
マイクロフロントエンドを管理する根底
-
機能毎のテクノロジーとの分離
-
各チームは実装に使う技術を他チームと調整せず選ぶ
-
[Custom Elements(Web Components)]によって実現
-
チームをまたいでコードを共有しない
-
チームのprefixを使う
-
分離だけは上手くいく様に、チームごとの変数やファイルのprefixを決めておく
-
CSS,Event,LocalStrage,Cookie
などを使う際に所属や衝突をはっきりさせるため
-
ブラウザネイティブのAPIを使う
-
コンポーネント間のデータのやり取りはできるだけブラウザネイティブの
Event
を使う
-
どうしてもAPIが必要ならできるだけシンプルに
-
不測の事態に強いサイトにする
-
jsが止まったり動かなかったりしてもそのサイトが動くようにする
-
体感パフォーマンスを上げるためにSSRやProgressive Enhancementを取り入れる
-
DOMがAPIになる
-
各機能ごとに
Custom Element
を実装して、機能を隠蔽することでタグ名がAPIとしての役割を果たす
-
-
※
Custom Element
は将来追加される HTML 要素の名前との衝突を避けるために、コンポーネント名に-を含まなければならない
-
コンポーネントを更新するとき
-
コンポーネント自体を置き換える
-
プロパティを書き換える→こちらの方が良いパフォーマンス
-
データの受け渡し
-
親→子
-
子→親
-
コンポーネントを結ぶAPIを実装する
-
子がEventを発火し、親がコンポーネントを区別せず受け取る
-
サーバサイドレンダリング
-
Custom Elementは初期描画が遅い & 失敗に弱い
-
jsのロードと実行まで画面に反映されないため
-
jsのロードや実行が失敗したら真っ白になる
-
Server Side Includes(かなり古い技術)→Nginxのみ?(syntaxが違うのかも)
-
URL経由でコンポーネントを配信する(Expressなど)
-
Nodeならnode-ssiなどを使用する
-
やってることは大体こんな感じ(node-ssiは少し高機能すぎる)
-
描画の再計算問題
-
コンポーネントを再描画(再でなくても)する際は、スタイルの再計算が行われる
-
ページレイアウトが更新される
-
-
これを避けるためには
-
レイアウトを固定する
-
Skelton Screenを作っておく
-
-
描画メソッドをコンポーネントの中身ではなく、一時的にコンテンツのスケルトンに置き換える
-
単純な変更の際は逆にスケルトンが一瞬だけちらつく場合があるので、あえて長く表示するなど調整する
-
読み込みが完了したことをどうやって判定する?
-
ajaxで取得したりする場合はそれで反映出来るけど、、、
-
ready
-
load
-
これは全要素なので一応これ
-
ただし、重い要素に全て引っ張られる
-
フロントエンドJSフレームワーク(React,Vue,Angular)など
-
Web標準のCustom Elementをサポートし動かしている
-
参考