大雑把にViewコンポーネントから責務をひっぺがしていくフロントエンド設計

Vue.js を利用すると仮定して、だいたいこんな感じに登場人物を分けるといいんじゃないかというメモ。View フレームワークのコンポーネントの分類の話ではなくて、コンポーネントに限らずに単純に責務を分離しようとしているだけ。

考え方の基本は以下の2点。

  • 並行作業のしやすさ(クリティカルパスの短縮)
  • テスト容易性の確保

以下、仮に UI を決める component の名前を UI.vue とする。なお、☆の数は現時点で考えている重要度を表す。

☆☆☆ Model.jsとの分離

データによって UI に変化が起きるデータバインディングの部分は「データ取得の仕組み」に依存してはいけない。

  • View が Vue コンポーネントから data をセットされる際、その仕組みの詳細に依存する必要はない
    • YAML を直接読み込んでいようが API にアクセスしていようが View には影響しない
  • つまり Vue コンポーネントの中にその仕組みの詳細を置いてはいけない
    • 置いてあったら詳細の変更の影響を受ける

上の考え方を適用すれば「View」と「データ取得、反映の仕組み」の開発は分離して同時に行えるのでお互いの作業をブロックしないし、それぞれ自動テストに対応させやすい。

もちろん、設計段階でお互いに連携しなければいけない責務は 考慮はしておく。例えばデータの取得に失敗した場合のユーザーへのフィードバックの方法などは Model でエラーの種類などを整理したうえで View にどうやって反映するかを考えておかなければいけない。

この辺をまず大雑把に Model と呼び、View component から分離しておく。この考え方で言う Model は特定のフレームワークに依存する必要はないので VanillaJS で書いておけばよい。attribute の扱いやエラーの扱いなどの共通の処理を内包するなんらかのライブラリがあるならそれを使ってもよいかもしれないが、Model すなわち State を持つ Store というわけではない。ここ重要。

☆☆ Container.vueとの分離

Container と Presentational の分離の話。methods, data, props, $emit の話。

例えば分離しておけば Model を仮置きしておいて後で差し替えるといった際に UI.vue 側は何も変更する必要がない。

cf. Vueで雑にContainer Component - あーありがち(2019-02-03)

☆☆ Error.vueとの分離

  • エラー処理をいちいち if で分岐すると処理の本質を追いにくくなる
  • 例えば Error.vue を用意し <Error v-if="errors.length > 0" :errors=errors> で丸投げ

ViewModel から見て model.errors と this.errors の 2パターン用意できるかも。

※ ActiveModel::Errors の考え方を転用。

☆ ModelとModelState.jsの分離

  • Model と ModelState は分けてよい
  • Flux 系 Store は State だけ担っていると考えればよい

☆ ModelとInteractor.jsの分離

Clean Architecture 的な意味での Interactor みたいな何か。Model 一つで処理できなければ、複数の責務にまたがる一つの処理にまとめる人を用意する。

errors も relay していく感じ。

まとめ

こんな構造になるかな。

Container.vue (3)
  `-- UI.vue (1)
  |    `-- Error.vue
  `-- Model.js (2)
  |    `-- errors
  `-- ModelState.js ( nearly equal Store ) (4)

順番としては 1, 2, 3, 4 で考えたらいいんじゃないかと考えている。Interactor を入れるとこんな感じかな?

Container.vue (3)
  `-- UI.vue (1)
  |    `-- Error.vue
  `-- Interactor.js (5)
  |    `-- ModelA.js (2)
  |    |    `-- errors
  |    `-- ModelB.js
  `-- ModelState.js ( nearly equal Store ) (4)

書いてみて思ったんだけど、こういう考え方だから、世間でよく観測される ViewModel コンポーネントの分類の話や Model == Store みたいな話にピンとこないんだなぁということが分かってきた。

More

Categories

Tool 日々 Web Biz Net Apple MS ことば News Unix howto Food PHP Movie Edu Community Book Security Text TV Perl Ruby Music Pdoc 生き方 RDoc ViewCVS CVS Rsync Disk Mail FreeBSD Cygwin PDF Photo Zebedee Debian OSX Comic Cron Sysadmin Font Analog iCal Sunbird DNS Linux Wiki Emacs Thunderbird Sitecopy Terminal Drawing tDiary AppleScript Life Money Omni PukiWiki Xen XREA Zsh Screen CASL Firefox Fink zsh haXe Ecmascript PATH_INFO SQLite PEAR Lighttpd FastCGI Subversion au prototype.js jsUnit Apache Trac Template Java Rhino Mochikit Feed Bloglines CSS del.icio.us SBS qwikWeb gettext Ajax JSDoc Rails HTML CHM EPWING NDTP EB IE CLI ck ThinkPad Toy WSH RFC readline rlwrap ImageMagick epeg Frenzy sysprep Ubuntu MeCab DTP ERD DBMS eclipse Eclipse Awk RD Diigo XAMPP RubyGems PHPDoc iCab DOM YAML Camino Geekmonkey w3m Scheme Gauche Lisp JSAN Google VMware DSL SLAX Safari Markdown Textile IRC Jabber Fastladder MacPorts LLSpirit CPAN Mozilla Twitter OpenFL Rswatch ITS NTP GUI Pragger Yapra XML Mobile Git Study JSON VirtualBox Samba Pear Growl Mercurial Rack Capistrano Rake Win RSS Mechanize Sitemaps Android JavaScript Python RTM OOo iPod Yahoo Unicode Github iTunes God SBM friendfeed Friendfeed HokuUn Sinatra TDD Test Project Evernote iPad Geohash Location Map Search Simplenote Image WebKit RSpec Phone CSV WiMAX USB Chrome RubyKaigi RubyKaigi2011 Space CoffeeScript Nokogiri Hpricot Rubygems jQuery Node GTD CI UX Design VCS Kanazawa.rb Kindle Amazon Agile Vagrant Chef Windows Composer Dotenv PaaS Itamae SaaS Docker Swagger Grape WebAPI Microservices OmniAuth HTTP 分析基盤 CDN Terraform IaaS HCL Webpack Vue.js BigQuery Middleman CMS AWS PNG Laravel Selenium OAuth OpenAPI GitHub UML GCP TypeScript SQL Hanami Dev Jekyll