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

Feb 06, 2019

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 みたいな話にピンとこないんだなぁということが分かってきた。

bluepillを知る

Feb 06, 2011

最近 Ruby 関係のことを知るのに都合のいい情報源は

E和の人のtweet
Stack Overflow

であることが多い。いやもちろんるびまも重宝していますが。

というわけで bluepill もそんな情報源から知った一つ。何かと思って調べたら Matrix 的なものではなく、

God が memory leak するから書いたものらしい。それ以外に気になるのは syslog に落とせるくらいか。そんなに大きな違いはないというかむしろものすごく God に似ている。

とりあえず今 God で困ってないんだけど、押さえておこう。

[2011-02-15 追記]

Ruby 1.9.2 の問題という話もあるみたい。

Twitter / @Tohru Hshimoto: そういえば、1.9.2ではrubyのバグのため安定し …

Net::SSH で明示的に password 認証に

Feb 06, 2009

twitter log 掘り起こし日記。

12:55:10 wtnabe< デフォルトと違う設定の ssh で capistrano を使おうとし
て大ハマり中
13:19:15 wtnabe< なんか :auth_methods の扱いもおかしいっぽいなぁ
13:20:57 wtnabe< passphrase を聞いてくるのが謎い
13:22:25 wtnabe< 自分自身の passphrase を使うわけではないので
:auth_methods を password に限定すると認証に失敗する
14:32:21 wtnabe< :ssh_options[:keys] = [] にしたら passphrase 聞いてこ
なくなった

Net::SSH 単体ではなく Capistrano で使っていたんだけど、

set :ssh_options[:keys], []

にしたってことです。

何のことかと言うと、自分の環境で ssh connection 絡みのテストをやると自動的に自分の config が反映されて面倒なことになっちゃったりするので、その辺をリセットするために行った措置だったりします。

※ 関係は薄いのですが password を Capfile の外から与えられないとまずいよなぁと思ったのと、どの程度のできるのか確かめたくて CLI.ui も試してみました。これは

HighLine

highline というライブラリを使っているわけですが、こいつが、なのか Capistrano の CLI の使い方が、なのか readline が効かない状態。対話的な処理を真面目に作り込もうとするとちょっとキツいかもしれません。

cap shell

は readline 効いてるのにね。

DOM で要素の絶対的な位置を計算してみる

Feb 06, 2007

※ 長さの割に内容はありません。先にあやまっておきますごめんなさい。

ことの発端はある部分のデータ量が多くてそこだけ縦に長くなっちゃってレイアウトが見苦しいので調整したいという要望だった。

んなもん紙じゃねーんだからバランス取ろうとする方がおかしいんだ

と思ったけれども、CSS（overflow: auto） + JavaScript（style.height をごにょごにょ）でなんとかなるかなーと思ってやってみた¹ら HTML の組み方によっては厳しいことが分かってきた。要は

旧石器時代に滅んだはずの table レイアウトってやつ

だ。あれは難しい。なぜなら table は内容全体に応じてセルの大きさが伸縮しちゃうからセルの大きさそのものは計算してもみんな同じなんだな、これが。中身がスカスカで見た目のバランスが崩れているかどうかは、セルの大きさを比較しても分からないわけ。

じゃあってんで内容の方に注目してその height を比較して調整すればいんじゃね？と思ったんだけど、デフォルトの margin なんかがあって意外とうまくいかない。マジックナンバーを投入するとなんとなくうまくいってるように見えるんだけど、ちょっと変更が入っただけで簡単に破綻してしまった。

じゃあ height じゃなくて注目している要素の bottom を比較できればいいんだなと思ったけれど、これをすんなり取得する方法は DOM にはないっぽい。offsetTop, offsetLeft てのはあるんだけどこれは親要素を原点としているので、ページレイアウト上の絶対位置は取得できない。

あれまーと思ったんだけどこういう方法で取得してみた。ある要素の上辺の、ページ内における絶対的な位置を取得する関数²。

function top( obj ) {
  var pos = 0;
  if ( obj ) {
    pos = obj.offsetTop;
    if ( obj.offsetParent ) {
      pos += top( obj.offsetParent );
    }
  }
  return pos;
}

※ 横着してますが obj は DOM の HTMLElement オブジェクトが入ってきていると思ってください。

offsetTop が親要素に対する相対位置なのだから、てっぺんの要素まで再帰でさかのぼって行けばいいじゃんていう話。試したところ狙い通りの値が取れてるみたいなんだけど、なんかおかしいこと考えてるかもしれないんで、気づいた方はツッコんでください³。一応 Opera 9, MacIE 5, WinIE 6/7, Safari 1.3, Firefox 1.5/2, iCab 3.0.2(build 382) で大丈夫みたい。つか今どきのフレームワークにはこういう機能すでにあるんかもしれんなぁ。

bottom の方は top + height を計算すればいいだけなので割愛。left, right も同じ要領なのでこれまた割愛。というかたぶん調整したいと言われるのは縦方向だけだと思う。