軽量オブザーバJSライブラリのrev.2をリリースした

ECMAScript Web

いわゆるリリースノート（宣伝とも言う）です。

少し前にこのブログで書いた、JS向けオブザーバパターンライブラリのrev.2をリリースしました。

Release · saneyuki/observer-js · GitHub

リリース概要

  • TypeScript用型定義ファイルを追加
  • ObserverSubject.destory()を追加
  • ObserverSubject.removeAll() -> ObserverSubject.removeTopic()に名前変更
  • Support IE6~8

First stable release

必要最低限のAPIセットが揃ったと考えたので、とりあえずstable releaseです。「とりあえずこれさえあればなんとかなるだろう」というAPIだけ載せました。将来的にIE6~8サポートは優先的に必ず削除する予定ですが、本バージョンのマイナーバージョンアップに留まるという選択肢が可能になります。ライブラリの規模も小さいからいざとなったら自分で直すっていう選択肢も取れるはず。

ライブラリ的にはECMAScript 5内で完結するように書いてるので、検証してないけどiOS5とかAndroid 2.3とかnodeでも動くはず。

TypeScript用定義ファイルの追加

あると便利だった（+人に勧めやすい）入れた。最初からTypeScriptで書けばlegacy IEサポートも簡単だったのかもしれない点に触れてはいけない。

API説明

詳しくはREADME内のAPI説明を読んでいただければと思います。

ObserverSubject.notify(topic, data)

  • 指定したtopicに登録されているオブザーバに対して、dataをまき散らします。
  • ECMAScriptというかJavaScriptはシングルスレッド動作なので実装上は同期的にオブザーバを呼び出しますが、設計としては非同期動作が前提です。当たり前のことですが、念には念を入れて注記しています。

ObserverSubject.add(topic, observer)

  • 指定したtopicにobserverを紐づける。

ObserverSubject.remove(topic, observer)

  • 指定したtopicからobserverを解除する。

ObserverSubject.removeTopic(topic)

  • 指定したtopicに紐づいたオブザーバをすべて解除する。
  • topicに紐づいたオブザーバを考慮すること無く、サブジェクト側で一方的に特定のtopicを削除したいケースを想定した機能。

ObserverSubject.destroy()

  • サブジェクトの明示的なデストラクタ相当の機能。
  • 自身に紐づくすべてのtopicに対して、ObserverSubject.removeTopic()します。
  • 自身に対してどのようなトピックが指定されているのかを一切知らずに一方的にサブジェクトを殺すのに使う、のを想定。
  • 単にfinalize処理用の明示的なデストラクタとして使う方が多いと思う。
  • ちなみに、destroy()した後のサブジェクトにadd()しようとすると、ES5 strict mode環境ではエラー吐きます。が、実装レベルでの挙動なので、そもそもdestroyしたサブジェクトにadd()とかしかねないコードは避けろ。
    • そのうち何かいい方法考えるかも。

Observer interface

  • 関数ではない。オブジェクトに実装しろ。

Observer.handleMessage(topic, data)

  • ObserverSubject.notify()を呼び出した際、notify()の引数として呼び出したtopicに登録されたオブザーバに限り、呼び出される。
  • notify()に渡した引数と同じものが引数と鳴る。
  • つまりはEventListener.handleEvent()だ。
  • 尚、オブザーバが呼び出される順番は保証しない点に注意。
    • 実装上、add()した順番で呼び出しているだけで、APIレベルでの保証ではない。

今後の予定

Legacy IEのサポート

個人的に必要なケースがあったので追加した。そのうち何が何でも落とす。絶対に落とす。

bowerサポートについて

そんなものはサポートしない。リポジトリに直接入れて問題ない規模であるし、そもそもポンポンとお役立ちシンタックスシュガーを入れる予定も無いので、パッケージ管理による高頻度なアップデートを想定していない。

AMDとか色々

ES6 Moduleには対応するが、そっちは対応するつもりが無い。軽量かつ全体設計のためのライブラリだと思っているので、非同期読み込みとかいろいろと安易にやるつもりが無い。

Adapter for Web Workers

考えてるけど、別ライブラリにした方がいい気もしている。

プロジェクト名変更

オーソドックスなオブザーバパターンの実装を意図しているので、名前を変える必然性がいまいち見当たらない……（元々自分のために作ったものだし）。bluebirdの例のように、適当な名前空間をでっちあげるかもしれないけど。

ライセンスヘッダがデカすぎる

minifyした場合、ライブラリ容量の半分をBSDライセンスの文章が占めているというギャグが発生しているので、そのうちなんとかしたい気もある。