Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Fat ComponentにしないためのWebフロントエンド設計 / Web Front-E...

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

https://lapras.connpass.com/event/179777 の登壇資料

サンプルコード
https://github.com/tooppoo/sample-for-vue-with-design-patterns
http://localhost:8080/first-class-collection-pattern/on-memory

参考資料
・オブジェクト指向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(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳)

関連する過去発表
・WEBフロントエンドにおけるソフトウェア設計の考察
 ・https://speakerdeck.com/tooppoo/consideration-of-software-design-in-web-front-end
・Vue.js + デザインパターンによるコンポーネント実装
 ・https://speakerdeck.com/tooppoo/vue-dot-js-dezainpatan-niyorukonponentoshi-zhuang-v2
・複雑なv-ifに負けないために
 ・https://speakerdeck.com/tooppoo/fu-za-nav-ifnifu-kenaitameni

philomagi

July 31, 2020
Tweet

More Decks by philomagi

Other Decks in Programming

Transcript

  1. 発表者 @Philomagi • WEB系プログラマ • 自称フロントエンド寄り ◦ 最近のマイブームは SelfとSmalltalk ◦

    vanila jsも久しぶりにちょっと触りたい • 設計の話とかが好きです ◦ DDDとかクリーンアーキテクチャとか ◦ 最近のSOLID原則の推しはI 2
  2. 9

  3. コンポーネント分割の効果と限界 • <template>や<style>の肥大化に対しては効果的 ◦ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる ◦ スコープが限定されることで、実装自体も単純化しやすい • <script>の肥大化に対しては限界がある

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

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

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

    ◦ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い ▪ v-if による表示分けのための計算など ◦ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難 ▪ 振る舞いが子コンポーネントに依存するため ▪ 「デザインは変わるが振る舞いは変わらない」が困難になる 肥大化の全ての要因をコンポーネント分割のみで解決するのは困難 26
  7. まずどこに注目するか 36 • UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い (≠データ)に注目する ◦ 「何がどのように見えるか」より先に、 見せるべき知識・情報は何か、それらはどのよう な構造・関連を取るか、に注目する •

    ユーザーは「カート内商品」の集まりである「カート内商品の一覧」に対して、特 定のカート内商品を「後で買う」「削除する」という操作を行うことができる • ユーザーは「カート内商品の一覧」に基づいて、合計数や合計金額を知ることが できる
  8. ユーザーの関心事に注目する 58 • ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄 (=知識・振る舞い)に注目する ◦ 「知識 ≠ データ」「振る舞い ≠

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

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

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

    CRUD操作」 ◦ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする ▪ FYI 「未来を作った人々」 • 注目すべき事柄をオブジェクトとして定義し、可視化する ◦ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の 相互作用(= interaction)も、「オブジェクト = 注目すべき事柄」に含まれる • 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい く
  12. FW・ライブラリとどう付き合うか 62 • 「FW・ライブラリを使いこなす」=「細かな機能をアプリケーション全体で全面的に利 用する」か? • FW・ライブラリは、自分たちが直面している課題を解決するための道具の一つでは あっても、特効薬そのものにはなり得ない • どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの

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

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

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

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

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

    かを考える • 何のために(Vue|FW|ライブラリ)を使うのか? ◦ 個人的には、Vue(のSFC)の html/css/js がそれぞれ自身の世界観を維持し ている形が好き ◦ Reactのような全てをjsの世界に引き込むのは、シンプルでプログラミングフレン ドリーなのだろうけれど、あまり好きではない
  18. • 「サーバーの「データ」をプリントするだけなんだから、フロントでやること は何も無い」 ◦ 振る舞いはどこにいった? • サーバーで提供・管理できる情報には限界が有る ◦ 画面側の一時的・揮発的な情報は、サーバーでは管理しようが無い ◦

    画面内部の動的な状態遷移も、サーバーでは管理・定義のしようが無い ▪ ex. ユーザー操作に伴うUIパーツ表示のON/OFF • 知識ではなく、データに強く注目・依存する考え方? 「JSON色付け係」 68
  19. • Smart UI アンチパターンが戒めているのは何もかもが区別無く一箇所に混在し た状態で、「画面に何らかのロジックが存在すること」ではない ◦ 「何もかもが区別無く一箇所に混在」 → 全部入りのVueコンポーネント •

    画面の状態や操作に関する「ロジック」を、画面以外の誰が管理するのか ◦ 動的な表示変更も、一切のユーザー操作も提供しない LPなら、「ロジック」は無いと 言って良いかもしれない ◦ しかし、LPを基準として語れるほど、現代のフロントエンドソフトウェアは単純ではいら れなくなっている • 「ロジック = ビジネスロジック」ではない ◦ ビジネスロジック ∈ ロジック Smart UI アンチパターン 69
  20. 70

  21. 雑感 74 • 古典的なMVCへ回帰する可能性 ◦ 実装のための「MVCパターン」というよりは、ソフトウェアの役割を規 程するものとしてのMVC ◦ Trygve Reenskaug

    • OOUIとの接続 ◦ この発表では、デザインよりプログラムに寄った視点から「オブジェ クト指向」+「UI」に注目している、とも言えるかも ◦ 行き着くところは似通いそう
  22. 参考資料 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(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳)