Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component

Slide 1

Slide 1 text

Fat Componentにしないための Webフロントエンド設計 1 @Philomagi 2020/07/31@Remove.vue #2 #remote_vue

Slide 2

Slide 2 text

発表者 @Philomagi ● WEB系プログラマ ● 自称フロントエンド寄り ○ 最近のマイブームは SelfとSmalltalk ○ vanila jsも久しぶりにちょっと触りたい ● 設計の話とかが好きです ○ DDDとかクリーンアーキテクチャとか ○ 最近のSOLID原則の推しはI 2

Slide 3

Slide 3 text

今回のテーマ 3

Slide 4

Slide 4 text

Fat Componentにしないための Webフロントエンド設計 4

Slide 5

Slide 5 text

注以降、特に断りが無い場合は「フロントエンド = Webフロントエンド」の意味で使います 5

Slide 6

Slide 6 text

注理由 ● 題材のベースがVue.jsである ● 発表者自身、Webフロントエンド以外のフロントエンド（デスクトップクライアント、iOS、Android）に詳しくない 6

Slide 7

Slide 7 text

Fat Component 7

Slide 8

Slide 8 text

8 ほんとうにあったVueコンポーネント

Slide 9

Slide 9 text

Slide 10

Slide 10 text

10 ←全体のおよそ1/5

Slide 11

Slide 11 text

11 約20行

Slide 12

Slide 12 text

12 約20行 <template> 約200行

Slide 13

Slide 13 text

13 約20行 <template> 約200行 <script> 約2200行

Slide 14

Slide 14 text

14 全体で

Slide 15

Slide 15 text

15 全体で約2500行

Slide 16

Slide 16 text

どうすれば防げたか or どうすれば改善できるか 16

Slide 17

Slide 17 text

主張 17 ● 何でもかんでもコンポーネントに書かない ● 表示・操作を実現するためのルール・制約・知識は、コンポーネントからは独立したものとして別途定義する ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングのみを記述する

Slide 18

Slide 18 text

主張 18 ● 何でもかんでもコンポーネントに書かない ● 表示・操作を実現するためのルール・制約・知識は、コンポーネントからは独立したものとして別途定義する ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングのみを記述する

Slide 19

Slide 19 text

主張 19 ● 何でもかんでもコンポーネントに書かない ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントからは独立したものとして別途定義する ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングのみを記述する

Slide 20

Slide 20 text

主張 20 ● 何でもかんでもコンポーネントに書かない ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントからは独立したものとして別途定義する ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングのみを記述する

Slide 21

Slide 21 text

主張 21 ● 何でもかんでもコンポーネントに書かない ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントからは独立したものとして別途定義する ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングのみを記述する

Slide 22

Slide 22 text

コンポーネントをもっと細かく分割する？ 22

Slide 23

Slide 23 text

コンポーネント分割の効果と限界 ● やの肥大化に対しては効果的 ○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる ○ スコープが限定されることで、実装自体も単純化しやすい ● <script>の肥大化に対しては限界がある ○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い ■ v-if による表示分けのための計算など ○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難 ■ 振る舞いが子コンポーネントに依存するため ■ 「デザインは変わるが振る舞いは変わらない」が困難になる 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

実装例 27

Slide 28

Slide 28 text

28 実装サンプル https://github.com/tooppoo/sample-for-vue-with-design-patterns

Slide 29

Slide 29 text

29 実装サンプル

Slide 30

Slide 30 text

実装サンプルカート内には複数の商品が存在する 30

Slide 31

Slide 31 text

実装サンプル 31 ・買う個数を変更・カートから削除・削除せず後で買うといった操作が可能

Slide 32

Slide 32 text

実装サンプル 32 カート内の・購入する商品数・購入時の合計金額を表示ただし、後で買う商品は除外

Slide 33

Slide 33 text

まずどこに注目するか 33

Slide 34

Slide 34 text

まずどこに注目するか 34 ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い（≠データ）に注目する ○ 「何がどのように見えるか」より先に、見せるべき知識・情報は何か、それらはどのような構造・関連を取るか、に注目する

Slide 35

Slide 35 text

まずどこに注目するか 35 ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い（≠データ）に注目する ○ 「何がどのように見えるか」より先に、見せるべき知識・情報は何か、それらはどのような構造・関連を取るか、に注目する ● ユーザーは「カート内商品」の集まりである「カート内商品の一覧」に対して、特定のカート内商品を「後で買う」「削除する」という操作を行うことができる

Slide 36

Slide 36 text

まずどこに注目するか 36 ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い（≠データ）に注目する ○ 「何がどのように見えるか」より先に、見せるべき知識・情報は何か、それらはどのような構造・関連を取るか、に注目する ● ユーザーは「カート内商品」の集まりである「カート内商品の一覧」に対して、特定のカート内商品を「後で買う」「削除する」という操作を行うことができる ● ユーザーは「カート内商品の一覧」に基づいて、合計数や合計金額を知ることができる

Slide 37

Slide 37 text

商品カートの構造 37

Slide 38

Slide 38 text

商品カートの構造ユーザーへ情報・振る舞いを提示するためのUIパーツ構造 38

Slide 39

Slide 39 text

商品カートの構造 UIを通じてユーザーが得る情報・振る舞い 39

Slide 40

Slide 40 text

商品カートの構造 40

Slide 41

Slide 41 text

商品カートの構造 41

Slide 42

Slide 42 text

商品カートの構造 UIとユーザーの間で発生するやり取り・相互作用 42

Slide 43

Slide 43 text

実際のコード 43

Slide 44

Slide 44 text

主張（再掲） 44 ● 何でもかんでもコンポーネントに書かない ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントからは独立したものとして別途定義する ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングのみを記述する

Slide 45

Slide 45 text

45 Vueコンポーネント

Slide 46

Slide 46 text

46 Vueコンポーネント

Slide 47

Slide 47 text

47 Vueコンポーネント

Slide 48

Slide 48 text

48 Vueコンポーネント

Slide 49

Slide 49 text

49 Vueコンポーネントコンポーネントのに書く内容は・htmlとオブジェクトプロパティ・イベントとオブジェクト操作のマッピングでほとんど終わる

Slide 50

Slide 50 text

50 Vueコンポーネント複雑な処理や計算はコンポーネントから切り出した個々のオブジェクトに任せる

Slide 51

Slide 51 text

51 Vueコンポーネント Vueコンポーネントは如何に知識を構成・表示・表現するかに注力する

Slide 52

Slide 52 text

52 Vueコンポーネント UIは詳細な処理・計算よりもユーザーに何を伝え、何を示すかに注力する

Slide 53

Slide 53 text

コンポーネント以外のコード 53

Slide 54

Slide 54 text

コンポーネント以外のコード 54 要するに普通のjavascriptのコード

Slide 55

Slide 55 text

コンポーネント以外のコード 55 普通のjavascriptのコードなのでテストに必要な準備も最低限

Slide 56

Slide 56 text

コンポーネント以外のコード 56 普通のjavascriptのコードなのでオブジェクト指向でも関数型でも既存の方法論を活用可能

Slide 57

Slide 57 text

考え方 57

Slide 58

Slide 58 text

ユーザーの関心事に注目する 58 ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄（＝知識・振る舞い）に注目する ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」 ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする ■ FYI 「未来を作った人々」 ● 注目すべき事柄をオブジェクトとして定義し、可視化する ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の相互作用（= interaction）も、「オブジェクト（目当て、対象）」に含まれる ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理していく

Slide 59

Slide 59 text

ユーザーの関心事に注目する 59 ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄（＝知識・振る舞い）に注目する ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」 ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする ■ FYI 「未来を作った人々」 ● 注目すべき事柄をオブジェクトとして定義し、可視化する ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の相互作用（= interaction）も、「オブジェクト = 注目すべき事柄」に含まれる ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理していく

Slide 60

Slide 60 text

ユーザーの関心事に注目する 60 ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄（＝知識・振る舞い）に注目する ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」 ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする ■ FYI 「未来を作った人々」 ● 注目すべき事柄をオブジェクトとして定義し、可視化する ○ 「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の相互作用（= interaction）も、「オブジェクト = 注目すべき事柄」に含まれる ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理していく

Slide 61

Slide 61 text

ユーザーの関心事に注目する 61 ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄（＝知識・振る舞い）に注目する ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」 ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする ■ FYI 「未来を作った人々」 ● 注目すべき事柄をオブジェクトとして定義し、可視化する ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の相互作用（= interaction）も、「オブジェクト = 注目すべき事柄」に含まれる ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理していく

Slide 62

Slide 62 text

FW・ライブラリとどう付き合うか 62 ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利用する」か？ ● FW・ライブラリは、自分たちが直面している課題を解決するための道具の一つではあっても、特効薬そのものにはなり得ない ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないのかを考える ● 何のために(Vue|FW|ライブラリ)を使うのか？ ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で行うため、と位置付けている ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる（実際、Vueは知識・振る舞いを構造化する方法は提供しない）

Slide 63

Slide 63 text

FW・ライブラリとどう付き合うか 63 ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利用する」か？ ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効薬にはなり得ない ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないのかを考える ● 何のために(Vue|FW|ライブラリ)を使うのか？ ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で行うため、と位置付けている ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる（実際、Vueは知識・振る舞いを構造化する方法は提供しない）

Slide 64

Slide 64 text

FW・ライブラリとどう付き合うか 64 ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利用する」か？ ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効薬にはなり得ない ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないのかを考える ● 何のために(Vue|FW|ライブラリ)を使うのか？ ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で行うため、と位置付けている ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる（実際、Vueは知識・振る舞いを構造化する方法は提供しない）

Slide 65

Slide 65 text

FW・ライブラリとどう付き合うか 65 ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利用する」か？ ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効薬にはなり得ない ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないのかを考える ● 何のために(Vue|FW|ライブラリ)を使うのか？ ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で行うため、と位置付けている ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる（実際、Vueは知識・振る舞いを構造化する方法は提供しない）

Slide 66

Slide 66 text

FW・ライブラリとどう付き合うか 66 ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利用する」か？ ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効薬にはなり得ない ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないのかを考える ● 何のために(Vue|FW|ライブラリ)を使うのか？ ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で行うため、と位置付けている ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる（実際、Vueは知識・振る舞いを構造化する方法は提供しない）

Slide 67

Slide 67 text

FW・ライブラリとどう付き合うか 67 ● 「FW・ライブラリを使いこなす」＝「細かな機能をアプリケーション全体で全面的に利用する」か？ ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効薬にはなり得ない ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないのかを考える ● 何のために(Vue|FW|ライブラリ)を使うのか？ ○ 個人的には、Vue（のSFC）の html/css/js がそれぞれ自身の世界観を維持している形が好き ○ Reactのような全てをjsの世界に引き込むのは、シンプルでプログラミングフレンドリーなのだろうけれど、あまり好きではない

Slide 68

Slide 68 text

● 「サーバーの「データ」をプリントするだけなんだから、フロントでやることは何も無い」 ○ 振る舞いはどこにいった？ ● サーバーで提供・管理できる情報には限界が有る ○ 画面側の一時的・揮発的な情報は、サーバーでは管理しようが無い ○ 画面内部の動的な状態遷移も、サーバーでは管理・定義のしようが無い ■ ex. ユーザー操作に伴うUIパーツ表示のON/OFF ● 知識ではなく、データに強く注目・依存する考え方？「JSON色付け係」 68

Slide 69

Slide 69 text

● Smart UI アンチパターンが戒めているのは何もかもが区別無く一箇所に混在した状態で、「画面に何らかのロジックが存在すること」ではない ○ 「何もかもが区別無く一箇所に混在」 → 全部入りのVueコンポーネント ● 画面の状態や操作に関する「ロジック」を、画面以外の誰が管理するのか ○ 動的な表示変更も、一切のユーザー操作も提供しない LPなら、「ロジック」は無いと言って良いかもしれない ○ しかし、LPを基準として語れるほど、現代のフロントエンドソフトウェアは単純ではいられなくなっている ● 「ロジック = ビジネスロジック」ではない ○ ビジネスロジック ∈ ロジック Smart UI アンチパターン 69

Slide 70

Slide 70 text

Slide 71

Slide 71 text

私たちの生活は今、コンピューターテクノロジーに囲まれており、仕事や遊びの場はますますソフトウェアの中へと移動しています。私たちはもはや物質や距離を意識せずに情報へアクセスし、コミュニケーションができます。私たちは1日の多くの時間をソフトウェアの世界で過ごしているのです。私たちがソフトウェアを利用する際に接するユーザーインターフェース（UserInterface：UI）は、もはやバーチャルな比喩的存在ではなく、リアルな目当て[オブジェクト]そのものなのです。オブジェクト指向UIデザイン──使いやすいソフトウェアの原理　「はじめに」 ([ ] 内は発表者による) 71

Slide 72

Slide 72 text

Slide 73

Slide 73 text

まとめ ● 「Vueを使っているから」とVueコンポーネントに何でもかんでも詰め込むと、程なくFat Componentに到達する ● どこまでをVueに頼り、どこからは自分たちの領域として守りたいのかを考える ● UIパーツだけでなく、その奥に潜む知識・情報・振る舞いにも注目し、構造化し、洗練させていく ● 知識・情報・振る舞いの精査を通じて、自分たちが実現しようとしているものを深く理解し、ソフトウェアに反映していく 73

Slide 74

Slide 74 text

雑感 74 ● 古典的なMVCへ回帰する可能性 ○ 実装のための「MVCパターン」というよりは、ソフトウェアの役割を規程するものとしてのMVC ○ Trygve Reenskaug ● OOUIとの接続 ○ この発表では、デザインよりプログラムに寄った視点から「オブジェクト指向」+「UI」に注目している、とも言えるかも ○ 行き着くところは似通いそう

Slide 75

Slide 75 text

参考資料 75 ● オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 ○ ソシオメディア株式会社 (著)、上野学 (著、監修)、藤井幸多 (著) ● MVCとはなにか ○ tenjuu99 ○ https://speakerdeck.com/tenjuu99/what-mvc-is ○ https://note.com/tenjuu99/n/n0232ccd1089d ○ https://note.com/tenjuu99/n/nbbb4b273676d ● MVC ○ Trygve Reenskaug ○ http://folk.uio.no/trygver/themes/mvc/mvc-index.html ● 未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明 ○ Michael Hiltzik（著）エ・ビスコム・テック・ラボ（監訳）鴨沢眞夫（訳）

Slide 76

Slide 76 text

ご清聴ありがとうございました 76