【Ltech#14】大きめレガシープロジェクトのフロント行く末

513 Views

March 01, 21

スライド概要

2021/03/02 Ltech#14 「LIFULL HOME'S」のフロントエンドについて語り尽くします!

中島拓哉

profile-image

LIFULL HOME'Sを運営する株式会社LIFULLのアカウントです。 LIFULLが主催するエンジニア向けイベント「Ltech」等で公開されたスライド等をこちらで共有しております。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

2021.03 大きめレガシープロジェクトのフロン ト行く末 約10年前に作られたLIFULL HOME'Sの現行サイト。負債化したJSは何が不十分で負債化したのか、最小限のコストでよりよい設計・規則を 導入するためにどう立ち向かっていくか Copyright© LIFULL Co.,Ltd. All Rights Reserved.

2.

大きめレガシープロジェクトのフロント行く末 Nakajima Takuya 2010年4月入社 アプリケーションエンジニアと入社して10年、現 在はややフロント寄りの業務をしている 学生時代にネトゲで嶌田氏と知り合い、その辺が きっかけでウェブ開発を始めた ウェブとDHHが大好き Copyright© LIFULL Co.,Ltd. All Rights Reserved. Twitter: @nazomikan

3.

大きめレガシープロジェクトのフロント行く末 LIFULL HOME’Sのサイト内情 10年前にリニューアル後、以降大きなリニューアルもなく開発され続けてきたサイト(部分的にマイクロサービス化して いる) アプリケーション側の技術スタック • Symfony2 • Twig • jQuery + Backbone.View的な設計 • Babel/Rollup/Sass/部分的にtypescript JavaScript files (ignore library) 1498 files. 136565 lines. Copyright© LIFULL Co.,Ltd. All Rights Reserved. おかしいな、さほど大きめではないような…

4.

大きめレガシープロジェクトのフロント行く末 既存コードでのViewの考え方 基本的にはBackbone.Viewと同じ考え方 テンプレートパーツと対になるJavaScript側のViewがあって、それ単位で 振る舞いを記述している Backbone同様にイベント機構の統一などは重なっている View同士の連携はグローバルなカスタムイベントを使ってやりとりして いた。 (Backbone.Eventsをグローバル放出してpubsubするのとほぼ同じ) Copyright© LIFULL Co.,Ltd. All Rights Reserved.

5.

大きめレガシープロジェクトのフロント行く末 解決されている問題 • コードの流れの統一 • eventsを見ればそのUIの振る舞いがわかる • • 全てのviewでそうなのでリードコストが削減される Viewごとの振る舞い定義によるファイル分割 (問題あり) Copyright© LIFULL Co.,Ltd. All Rights Reserved.

6.

大きめレガシープロジェクトのフロント行く末 後にわかるコードの隙 結局なくならないDOM探索 • DOM探索で埋漏れるビジネスロジック • セレクタに依存してDOMの変更に弱い • 似た少し違うコードが量産されて、build時間が増大して いく • 横方向の区切りはできても縦方向のviewの境目が守られない • 安易なDOM探索が子,親viewを犯してしまう • 親・子分割がうまく行かず巨大な親だけ作られていく • インスタンスが露出して外部から使役される懸念が残る • XHR等で後に挿入されたHTMLへの振る舞いのアタッチが手動 になり、それでまたビジネスロジックが汚染される Copyright© LIFULL Co.,Ltd. All Rights Reserved.

7.

Copyright© LIFULL Co.,Ltd. All Rights Reserved.

8.

DHH say: 「HTMLとJavaScriptの概念的距離を圧縮したい」 HTMLとJavaScriptはよく見ると、PHPとmysqlみたいな関係にある セレクタというQueryを投げてDOMを得ている データアクセスには手続きが必要で、壊れやすく、ビジネスロジックはそ のコードに埋もれ、さらには独特なそのデータ形式(NodeList等)の normalizeに苦心する DOMが変数やプロパティにアクセスするかのように簡単に参照でき、それ らへのアクセスに制限を設けることができれば問題は軽減する Copyright© LIFULL Co.,Ltd. All Rights Reserved.

9.

大きめレガシープロジェクトのフロント行く末 At modern library • JavaScriptの中にDOMを記述することでDOMの参照を探索せ ずに実現している • これもHTMLとJavaScriptの概念的距離の圧縮に成功し ている Copyright© LIFULL Co.,Ltd. All Rights Reserved.

10.

Use React/Vue? Copyright© LIFULL Co.,Ltd. All Rights Reserved.

11.

大きめレガシープロジェクトのフロント行く末 しぶり続けて早5年、理由はよくあるやつ • Existing DOMの安心感はなんだかんだ半端ない • JavaScriptが最悪動かなくてもHTMLドキュメントとして最低限機能を果たしてくれる • SEO的な懸念の回避 • インデックスが遅いだけで大丈夫とか、心配ならSSRすればとかあるけどそもそも そんな不安や複雑性を抱えたくない • 現行の資産(負債)の大きさ故にシステム構成レベルの変革を望まない • 負債は一括返済ではなく分割で返済したい • • カバーする領域がJavaScript領域に閉じてない • 将来的な別ソリューションの登場時に撤退容易性が低い • • 返さなくていい負債は返すつもりもない 命預けるなら普遍的なHTMLを軸にしたライブラリにしたい 将来的にビルドプロセスをなくしたいのでxxx-loader系と縁を持ちたくない • ビルド時間を気にしたり、ビルド設定に時間を費やすのはソフトウェアライターとして本 質的ではない Copyright© LIFULL Co.,Ltd. All Rights Reserved.

12.

大きめレガシープロジェクトのフロント行く末 わがままな私たち • Existing DOMのアプローチでDOMアクセスを省略できて、インスタンスを隠蔽できて、振る 舞いのアタッチを自動化できたらそれが一番いい • ついでに流行りのライブラリのようにHTML側からみて振る舞いが宣言的であれば嬉しい • ブラウザの敷いた道から離れたくない (戻るの大変なので) • WebComponentsがやや近しい?気がしてそれの発展に期待していた • 振る舞いの自動アタッチ • インスタンスの隠蔽 • DOMアクセスの制限(shadow root内に限られる) Copyright© LIFULL Co.,Ltd. All Rights Reserved.

13.

そんなこんなで負債を 垂れ流し続けたある日 Basecamp製のStimulusが熱いゾ Copyright© LIFULL Co.,Ltd. All Rights Reserved.

14.

大きめレガシープロジェクトのフロント行く末 Stimulus • Basecamp製のJavaScriptライブラリ (thx. dhh, sstephenson, javan • Existing DOMアプローチ • DOMの変更をMutationObserverで監視し、対象のDOMが出現したら自動で定義した振る舞いをアタッチする。 • 操作したいDOMを明記しておくとgetterメソッドが自動で作られてプロパティのようにアクセスできる data-cotrollerでHTMLと JavaScriptを接続 data-action=“evt>controller#method”で要素に 振る舞いをアタッチ data-[controller]-target=“xxx” の要素にthis.xxxTargetでアク セス Copyright© LIFULL Co.,Ltd. All Rights Reserved.

15.

Copyright© LIFULL Co.,Ltd. All Rights Reserved.

16.

大きめレガシープロジェクトのフロント行く末 Stimulus is great solution • Existing DOMの絶対的安心感 • アクセスするDOMは事前に定義でき、それらはシームレスにプロパティとしてアクセスできる • HTML側にアクセスする要素を記述するのでJavaScript側はHTMLの構造変更の影響をほぼ受けない • 振る舞いは自動でアタッチされインスタンスの隠蔽で悩む必要はない • HTML側からみて振る舞い、状態が宣言的である • HTMLの出現時に自動で振る舞いや状態がアタッチされるのでサーバ側からは大きなjsonを返す必要はなくHTMLを返 せばいい • • 必然的に型・スキーマの重要性が下がる Primitiveなcontrollerの再利用製の高さ • DOMをセレクタで探索するのではなくDOM側に対象を明記するのでDOMの構造差異に強く振る舞い自体の再利 用製が高い • disclosure/remover/modal/content-loader等、再利用製高い単一用途のcontrollerを作ってガンガン再利用できる Copyright© LIFULL Co.,Ltd. All Rights Reserved.

17.

大きめレガシープロジェクトのフロント行く末 LIFULL HOME’Sの戦略 • stimulusでHTMLとJavaScriptの概念的距離を縮め、さらには振る舞いを宣言的にする • 全移行はコストかかるので本気ださない • • 長い期間、既存設計と併用になるがそれを厭わない(困らないので) • 新しくそこを触るときにstimulusで置き換えられるところをそっと切り出すだけでいい Build Processをいつか捨てるという夢は諦めない (ie11が死んだ暁には…) • bye babel, bye bundler, bye transpiler • アプリケーションの設定的な複雑性から解放されたい • PrimitiveなControllerを大量生産してコード量を1/20(次期目標)にしていく • 新規開発において既存のcontrollerをロードしてhtml側で属性組み立てるだけでそのページの振る舞いが完成すること が夢 • 書いたコードは例外なく将来負債になる • コードは書かないに越したことはない Copyright© LIFULL Co.,Ltd. All Rights Reserved.

18.

大きめレガシープロジェクトのフロント行く末 LIFULL HOME’Sの戦略 HTMLを大事に Webに素直に Copyright© LIFULL Co.,Ltd. All Rights Reserved.

19.

大きめレガシープロジェクトのフロント行く末 終 Copyright© LIFULL Co.,Ltd. All Rights Reserved.