改めてVue.jsのデータの監視方法と回避方法とコンポーネント設計

May 13, 2018

まとめ

Vue で監視していたのは data ではなく setter を通ったかどうかだった
- そこは Backbone.js 時代から変わってなかった
Array や Object の一部を書き換える処理は setter を通らないので Vue は検知できない
逆に丸ごと壊せば setter を通すことはできる
しかし恐らくその場合は書き換える DOM の範囲が広がり、VirtualDOM の速さのメリットがスポイルされる
コンポーネントを小さくしろというのはそういう意味でもあった

参考

Arrayの変更、Objectの変更はsetterを通らないので検知できない

まぁ、分かってしまえば当たり前の話なんですけど、こういう感じのコードがあると思いねぇ。

data() {
  return {
    model: {}
  }
},
methods: {
  action() {
    this.model['foo'] = 'bar'
  }
}

これ、data だからとか computed だからとか watch じゃないからとかじゃなくて、Vue では検知できないです。

これはごく簡単な理由で

this.model = {foo: 'bar'}

じゃないと setter を通らないから。つまり、

Vueは値は監視していない。setter が通知してるだけ。

そうと分かれば話は簡単。つまり Bachbone.Model の時代から本質は変わっていないわけです。あの頃は Model 側も event を通知する処理を自前で書いていましたが、その部分の記述が setter を通すことで省略できているだけ。

じゃあ検知させたければsetterを通せばよい

その通り。setter を通せばよいのです。

上のコードを本当に動くようにすると以下のようになります。

methods: {
  action() {
    let model    = JSON.parse(JSON.stringify(this.model))
    model['foo'] = 'bar'
    this.model   = model
  }
}

こうすれば setter を通るので複雑なデータ構造でも reactive system を動作させることができます。

でも関係するVirtualDOMは全書き換えになっちゃうし、影響も把握しにくい

当たり前ですね。そうなるとせっかく変更のある部分だけ書き換えることを容易に実現できる VirtualDOM の特長が犠牲になるわけです。例えば Array の変更を setter で通知してしまうと、v-for で回している部分は全書き換えになります。

さらに複雑で深い構造のデータを data として保持していて、もしそれがそのまま表示に関係している場合、その component と子の component など、多くの場所でこの data の書き換えの影響を受けます。言い換えると component が大きすぎるわけです。これは実行速度でもマイナスですが、変更もテストもやりにくくなります。¹

素直にsetterで渡せる範囲がVue componentの適切な大きさの一つの指針なのかも

今回 setter の存在に改めて行き着いて、複雑な構造のデータの変更を無理矢理検知させることをやりましたが、本当はこれは Vue 的にはオススメできない方法のような気がします。

今回気づいた setter の動作が理想的なものなのか技術的な制約に基づく妥協なのかは分かりませんが、少なくともフレームワークにとって自然な動作を満たすようにしておくというのは、他の人とコードや知見を共有する際に有効です。逆にイレギュラーな使い方はこの共有を難しくします。

「component は小さく」とはよく言われますが、もしかしたらこの setter を意識せずに使える範囲こそが、component の適切な大きさなのかもしれないという、改めて考えるとごくごく当たり前のことに気づいたという話でした。

落穂拾い

以下、うまくハマらなかったものを殴り書きして終わります。

「component は小さく」とは言いますが、不必要に作りすぎても管理が大変です。小さく保つのは大事ですが、すべてを component に分ける必要はないと思います。

props バケツリレーは確かに面倒ですが、2, 3 階層程度なら割と慣れます。

props で渡すデータの数が増えてもあんまり気にしない方がいいかも。function の引数とは意味が異なると捉え、何も考えずに {{ }} で展開できる単純さを優先してもよいと思います。「責務が一つであればデータは一つでなくてもよい」という考え方。

例えば自動テストをするにしても初期化、stub out が面倒です。 ↩

Thunderbirdの受信メールのヘッダを書き換えてImportし直す

May 13, 2010

Thunderbird

結論

受信したメールを書き換えたい場合、いったんメールを .eml で保存して必要な書き換えを行ったあと、

ImportExportTools

を使って .eml を Import することで可能。

書き換えを Thunderbird 上で行うツールがあるのかどうかは分からない。

背景

Subject なしで割と重要なファイルを添付したメールを受け取った
このままでは検索できないので受信メールの Subject を書き換えたい
そんなことできるの？拡張にある？

書き換えの拡張を探し始めたけど見つからず、Thunderbird の外で書き換えればいいんじゃないかというアイディアを確か他の人にもらって探したら見つかった。

直接編集なので MIME encode は自力でどうぞ

Subject などヘッダは MIME encode されているのでエディタでそのまま編集するのはつらい。自分の場合は手元の irb で

NKF.nkf( '-M', 'あいう' )

とかやるとすぐに得られるので苦労はないんだけど。

※ Un*x 版の nkf はデフォルトで iso-2022-jp への変換を行うので、-M で MIME encode してやるだけでよい。でも最近の nkf のマニュアルにはこの辺が明示されていないっぽいので、もしかしたらそのうち挙動が変わるかもなぁ。

dom0 と domU の時計が意図せず食い違うケース

May 13, 2008

以前書いた内容は間違ってたっぽいんですが、あまり見ないケースだと思うのでとりあえず現象をそのまま書いておきます。

えー結論から言うと

dom0 が正しく ntp サーバと同期できていない domU の時計は dom0 とも食い違う可能性がある

ということです。自分はそんなケースを考えていなかったので、あちこち調べた結果

domU では ntpd を立てない
dom0 で ntpd を立てる

状態にして、まさか ntp サーバが調子悪くなってると思わず放置してたのですが、しばらくして domU の時間がずれているなぁという話になりました。いやー dom0 に合ってるはずなんですけど？って返したら dom0 とも違うなぁということで色々調べた結果ホスティング先の用意している ntp がおかしなことになっている。(Stratum 16 とか言う。)

前回はこの現象を早合点して RH 系 Linux の domU は自分で時計合わせなきゃダメなんだ！と思い込んでしまったのですが、実際にはそうではなく、単に dom0 が時計をちゃんと合わせてくれないと domU は domU で dom0 とは独立して勝手にずれていく、ということだったようです。

で、今はデフォルトの状態のまま¹ dom0 でも domU でも ntpd を動かしているのですが、これはこれで変というか。

時計はずれてないけど syslog に ntpd が時計を合わせた旨もエラーメッセージも記録されないのです。10日ほど。ntp の設定を見直したまさにその日にしか記録がない。これはおかしいなぁ。でも時計は正確なのです。

ntpd のエラーってなんか conf に書かないと記録されないんだっけか。LAN 内のものは特に設定しなくてもコマゴマ記録されてるんだよな。この状況はまずいんだろうかまずくないんだろうか。もう一回 domU の ntpd を止めて様子見ようかなぁ。RH 系 Linux はそういうもんなのかな。Debian 鯖と記録のされ方がなんか違うな。