[2021/08/24] Frontend Night

[jjenko]

Policy

• 資料の準備をがんばらない
• 参加・途中退席は自由
• スキップしない

話したい・聞きたいネタを書いてく ✏️

ハッシュタグ #frontend_night

Prev: #158

Created from #65 by issue-creator

[kobayang]

A Deep Dive into Airbnb’s Server-Driven UI System

c.f. 要約版: https://www.infoq.com/jp/news/2021/08/airbnb-server-driven-ui/

• Server-Driven UI (SDUI) は、サーバーがデータだけでなくUIも提供するという考え方。
• Airbnb は Ghost Platform(GP) という Server-Driven UI System を実装している。

SDUI にする嬉しさ

Traditional	SDUI

ref: https://www.facebook.com/watch/?v=1445539065813160 31分〜

UIに関するロジックやビジネスロジックをサーバー側に集約できること。
あとはモバイルのversioningでもSDUIの利点があると言ってる。

Ghost Platform(GP)

GP は UI を スクリーンとセクションという概念に分けて考えてる。

GP の Core Concept

• セクション
  • data を UI に変換する
  • ディスプレイに表示する正確なデータ & l18n
  • セクションは スクリーンや外のセクションのことを知らない
• スクリーン
  • セクションがどこに配置されるか、どのようにセクションを表示するかの情報を持つ(Placement と呼ぶ）
  • レスポンスをリアルタイムに反映する + 後方互換生がある

ref: https://www.facebook.com/watch/?v=1445539065813160 35分ぐらい

• アクション
  • Swipe などのアクションのタイプを指定することでインタラクションを表す。

よく分からなかったこと

• インタラクション後のUIの変更はどう表現してる？
  • リアルタイムにレスポンスを瞬時に反映させていると言っているのでそれで表現可能？
• 初期描画時のレスポンスがめちゃくちゃ巨大になりそう？
  • パフォーマンス的にどうなの。

感想

• 真に規約化されたDesignSyetemがあればできるんじゃないかという夢を感じる
• セクション、レイアウトという考え方は UI を実装する上で参考になる。

[kobayang]

メルカリShops のフロントエンド

📝 面白いと思ったポイント

• UI
  • chakra-ui を使ってる
• GraphQL
  • Reactive Variablesによるステート管理
  • Apollo Link の中で認証処理を実装している
• キャッシュ戦略
  • SSR/CSR のルールを最初に定義する
  • stale-while-revalidate を多段構成にする
    • c.f. Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新
  • Service Worker では HTML は常にネットワーク優先
  • 全体パージ用のキーと個別用のキーを Surrogate-Key に入れキャッシュをパージする
    • c.f. CDN とキャッシュの仕組み

[kobayang]

新しいメルカリDesign System Web

Design System Webはメルカリ Webで使われているReactだけでなく、様々な技術スタックと共に使用できる、真にスケーラブルなライブラリでなくてはなりません。また、各ライブラリの仕様に引っ張られて細かい箇所で挙動が違ったり、メンテナンスや実装速度の都合上仕様に差分が出てくることは避けたいと考えていました。以上のことから、新しいDesign System Webを構築する技術スタックはWeb Componentsを採用しました。

Web Componentsを構築するためのライブラリはLit (採用の時点ではLitElement)を採用しています。これはシンプルな分カスタムが効きやすいという判断です。

c.f. Lit

Lit の話は https://uit-inside.linecorp.com/episode/84 のエピソードで語られていたのでおすすめ。

React上でWeb Componentを使うにはいくつかの問題があります。これを解決するためにReact Wrapperと呼ばれるライブラリを実装し、それぞれのコンポーネントに対するEvent Listener、JSXの型付け、attributeの型変換などをサポートするReact Componentを各コンポーネントごとに生成しています。

https://custom-elements-everywhere.com/

データの取り扱い

ReactはすべてのデータをHTML属性の形でCustom Elementsに渡します。プリミティブなデータの場合はこれで問題ありませんが、オブジェクトや配列のようなリッチなデータを渡す場合はシステムが破綻します。このような場合、some-attr="[object Object]"のような文字列化された値になってしまい、実際には使用することができません。

イベントの処理

Reactは独自の合成イベントシステムを実装しているため、回避策を使用せずにCustom ElementsからのDOMイベントをリッスンすることはできません。開発者は、refを使用してCustom Elementsを参照し、addEventListenerでイベントリスナーを手動でアタッチする必要があります。これにより、カスタムエレメントの扱いが煩雑になります。

📝 感想

• 社内でもrails用(sass)のとReactのデザインシステムが混在しているのでWebコンポーネントにするのはありでは
• React と Web Components の相性が良くないのが結構不安。
• Lit素振りしたい。（個人的感想）

参考

• Web Componentsで作られているDesign System ライブラリ

[izumin5210]

facebook/react#22114