RxJS を使って、Vuex のようなものを書いた

散歩していたときにふと思いついたので書いてみた。

Vuex のゲッター、Vue の算出プロパティの実装は Observer パターンが適用されているので、Observer パターンが根底にある Rx で上手く実装できるんじゃないかな、という思いつきだったんですが、思いの外、簡単にできました。 ステート、算出プロパティ(ゲッター)、アクション、ミューテーションを一通り実装していますが、アイディアの検証レベルで書いたものなので、算出プロパティの依存関係を明示的に指定しないといけなかったり等、細かいところは色々違っています。

const Rx = require('rx-lite')

class ReactiveProperty {
    constructor(state, name, initialValue) {
        this.subject = new Rx.BehaviorSubject(initialValue);
        this.changed = this.subject.skip(1);

        Object.defineProperty(state, name, {
            get: () => {
                return this.subject.getValue();
            },
            set: (val) => {
                this.subject.onNext(val);
            }
        });
    }
}

class ComputedProperty {
    constructor(store, name, dependencies, getter) {
        this.subject = new Rx.BehaviorSubject(getter(store));
        this.changed = this.subject.skip(1);

        Rx.Observable.combineLatest.apply(null, dependencies.map(function (dep) {
            return dep.changed;
        })).subscribe(() => {
            this.subject.onNext(getter(store.state));
        });

        Object.defineProperty(store.computed, name, {
            get: () => {
                return this.subject.getValue();
            }
        });
    }
}

class Store {
    constructor(options) {
        this.state = {};
        this.computed = {};
        this._actions = options.actions;
        this._mutations = options.mutations;

        this._properties = {};

        for (let name in options.state) {
            this._properties[name] = new ReactiveProperty(this.state, name, options.state[name]);
        }

        for (let name in options.computed) {
            let computed = options.computed[name];
            let dependencies = computed.slice(0, computed.length - 1).map((name) => {
                return this._properties[name];
            });
            let getter = computed[computed.length - 1];
            this._properties[name] = new ComputedProperty(this, name, dependencies, getter);
        }
    }
    dispatch(action, payload) {
        return new Promise(() => {
            return this._actions[action].call(this, {
                commit: this.commit.bind(this),
                state: this.state
            }, payload)
        });
    }
    commit(mutation, payload) {
        return this._mutations[mutation].call(this, this.state, payload);
    }
    watch(name, callback) {
        return this._properties[name].changed.subscribe(callback);
    }
}

const store = new Store({
    state: {
        firstName: 'John',
        lastName: 'Smith',
        amount: 10
    },
    computed: {
        fullName: ['firstName', 'lastName', function (state) {
            return state.firstName + ' ' + state.lastName;
        }]
    },
    actions: {
        increment: function (context) {
            return new Promise(function (resolve) {
                setTimeout(function () {
                    context.commit('increment');
                    resolve();
                }, 1000);
            });
        }
    },
    mutations: {
        increment: function (state) {
            state.amount += 1;
        }
    },
});

store.watch('firstName', function (name) {
    console.log('firstName changed:', name);
});

console.log(store.computed.fullName); // John Smith
store.state.firstName = 'Bob';
console.log(store.computed.fullName); // Bob Smith

console.log(store.state.amount); // 10
store.commit('increment');
console.log(store.state.amount); // 11

process.on('exit', () => {
    console.log(store.state.amount); // 12
});

store.dispatch('increment');

最近の仕事では Vue や Vuex を選択することが多く、今のところはある程度うまくいっていると感じているんですが、プロジェクトの数年先を考えて、Vue や Vuex が担っていることを因数分解して、他の何かで置き換えることができないか、といった思考実験や検証をちょいちょいおこなっています。 今回は(RxJS に依存してはいるんですが)Vuex を何か他のものに置き換えることはできるか、というところで上のようなコードを書いてみました。

かくかくしかじか を読んだ

読んだ。

かくかくしかじか 5 (マーガレットコミックスDIGITAL)

東京タラレバ娘、海月姫の東村アキコの伝記的な漫画。高校時代から始まり、漫画家としてデビューするまでの絵の「先生」との交流を描く。

作者の中身を全て曝け出すような心理描写と「先生」が繰り返し発する「描け」というメッセージに心が揺さぶられた。

Vue.js のリストレンダリング( Virtual DOM 実装 )と相性の悪いデータの変更

この間、現場で直面したやつの個人的なメモです。対象のバージョンはこの記事を書いている時の最新バージョン v2.3.0。

以下のようなリストレンダリングをおこなうコンポーネントがあるとして、

<script>
export default {
  name: 'list',
  data() {
    return {
      items: [1, 2, 3, 4, 5]
    };
  }
}
</script>

<template>
  <ul v-for="item in items" :key="item">
    <li>{{ item }}</li>
  </ul>
</template>

items のサイズの上限を 5 として、新しいデータを追加したい場合は古いデータを削除することとする。
例えば、items [1, 2, 3, 4, 5] に 6 と 7 を追加する場合、items は [3, 4, 5, 6, 7] になるが、Vue.js の Virtual DOM 実装は以下のような diff/patch を適用する。

• 新しい vdom の先頭の 3 が古い vdom にないか探し、見つかったので 3 のアイテムの DOM 要素をリストの先頭に移動させる(ここで key 属性の指定が効いている)。4, 5 も同様。
• 6 は無いので、新しく DOM 要素を生成して追加する。7 も同様。
• ここまでで 3, 4, 5, 6, 7, 1, 2 と要素が並んでいる。1 の要素は不要なので削除する。2 も同様。

以上で、新しいデータが Real DOM に反映された。このロジックは updateChildren 関数 (vue/patch.js at v2.3.0 · vuejs/vue · GitHub) に書かれている。上から下に読んでいくと分かりづらいので、上記のようなサンプルを用意し、DOM に Breakpoint を設定して実際にコードを動かしながら処理を追っていくと読みやすい。
本来であれば、1, 2 をそれぞれ変更して末尾に移動させるのが最も効率が良いはずだが、リストの最大サイズ + 変更のあった件数分 の DOM 操作が必要になる。リストの最大サイズが増えれば増えるほど、時間がかかる。

自分の場合は、最大サイズがそれなりに多かったのと、データの更新頻度が多く、Script の処理が増えて、fps がかなり低下してしまった(Timeline で調べたら、updateChildren 関数が Script 処理の 80% 以上を占めていた)。結局、この部分は直接 DOM 操作をおこなうことにした。Virtual DOM は、大体のケースである程度うまくいくが、このように極端なケースではうまくいかない。

ちなみに、フォームで何かを入力してボタンを押したらデータを1件追加する、あるいはリストから1件アイテムを削除するといったよくあるケースの場合は DOM 操作が 1 回で済むようになっている。

ウェブアプリのパフォーマンスに対する共通の捉え方を持つ

最近、一緒に仕事をしている企画者に「ブラウザAでページBを開いたら重かったです」と言われたことがあって、そのときに思ったこと。

「重かったです」と言ってくるということは何か良からぬことが起きている気がするけれど、それだけだと何が起きているのか、何が問題なのかがよく分からないので、以下のような質問で原因で探っていく。

• ページの表示が遅いのか
• 操作(スクロールやクリック)の反応が悪いのか
• アニメーションが滑らかでないのか

このような質問をしていて思ったのは、ウェブアプリのパフォーマンスに対する捉え方を啓蒙したり、互いに共通の捉え方を持つといいのかもしれない、ということ。例えば、上記の質問は、自分が知っている RAIL というパフォーマンスモデルに基いて行った質問だった。RAIL はウェブアプリのパフォーマンスをユーザーの体験から4つの側面で捉えたモデルで具体的な内容は RAIL モデルでパフォーマンスを計測する  |  Web  |  Google Developers の解説が詳しい。

一度、こういったパフォーマンスモデルを共有しておけば、以後は冒頭のようなやりとりがスムーズにおこなうことができる。また、エンジニア同士でも「とりあえず改善しました」系の PullRequest がなくなり、RAIL のどの側面でコードを具体的にどのように修正したかが明らかになる。それにより、コードレビューが行いやすくなったり、なんとなくな改善を手当たり次第におこなうことが無くなるのではないだろうか。

date-fns に乗り換えて、スクリプトのファイルサイズを削減した

題の通り。

Browserify を使ったプロジェクトでファイルサイズを大きくしているライブラリを探す - kitak.blog で moment がけっこうな割合を占めているということを書いたのだけど、少し前に moment から date-fns に乗り換えて、ファイルサイズを削減できた。

moment がオブジェクトから日付操作などの様々なメソッドを呼び出すことができるのに対し、date-fns は 日付に関係するユーティリティ関数が集まったライブラリといえる。

例えば、date-fns でふたつの日付が同じ週か調べる場合は以下のようになる。

import isSameWeek from 'date-fns/is_same_week'

const result = isSameWeek(
  new Date(2014, 7, 31),
  new Date(2014, 8, 4)
)

日付操作の関数を必要に応じてインポートするので、Browserify, Rollup, Webpack のようなモジュールバンドラを利用した場合に、ブラウザの JavaScript エンジンで実行される(本当に必要な)コードだけバンドルされる。 自分が担当しているプロジェクトだと moment をバンドルした場合と比べて、900k 程度削減することができた。

もし、moment を使っていて、ほんの一部のメソッドしか使用していない、かつファイルサイズを削減することに意義のあるプロジェクトなのであれば、date-fns への乗り換えを考えてみてもいいかもしれない。

また、自分でライブラリを作る際に、(moment のようにオブジェクトのI/Fにする方が適切なケースもあるかもしれないが) date-fns を参考にして、モジュールバンドラフレンドリーなライブラリにできないか考えてみてもいいかもしれない。関数毎にファイルを分割したり、Tree Shaking が効くように ES2015 の Named export でモジュールを定義する、等など。

誰が音楽をタダにした? を読んだ

読んだ。

mp3 が世の中に普及して音楽業界を変えるに至った話をストーリー仕立てでまとめた一冊。

mp3 を生み出した研究者、音楽業界、「シーン」と呼ばれるインターネットの地下コミュニティ、この3つの糸が絡み合いながら、物語が進行していく。自分にとって、mp3 は物心がついた頃から当たり前の存在なのだが、正直、それが生まれた経緯であったり、世の中に普及した経緯は全く知らなかったので興味深く読めた。

誰が音楽をタダにした？　巨大産業をぶっ潰した男たち【無料拡大お試し版】 (早川書房)

ルパート・サンダース監督 Ghost in the Shell を観た

今日の午前中に、渋谷の TOHO シネマズで観た。

都市や街並みの映像が良かった。単純にきれいだし、アニメ映画版、イノセンスと続く、ブレードランナーの DNA の系譜を継いでいるように感じた。 また、ひとつひとつのシーンの撮り方や、各所に散りばめられた小道具から、アニメ映画版やイノセンスに対するリスペクトも感じた。ガブリエルかわいいよ。

一方、映画の時間の長さ上、致し方ない気がするのだけど、公安9課のポジションがいまいちパッとしなかったのと、ひとつひとつの場面が明快で、全体としてきれいにまとまりすぎていて物足りなさを感じてしまった。イノセンスのように難解でなくていいのだけど、Stand Alone Complex の Stand Alone エピソードのような見終わった後の余韻、Complex エピソードのようなもう一度見たくなる程度の難しさが脚本に欲しかった。映像の質やスカーレット・ヨハンソンが演じる少佐の演技が良かっただけにそこがもったいないな、という気持ちになってしまった。