これは?
社内発表のコードの反省会/説明/言い訳 用です。主に下記になります。
- きになる点
- 省いて(ズル)いる点
やったこと
- 同じアプリケーションをそれぞれのアーキテクチャを用いて作成
- xhr , アニメーション , シーケンサー(イベント発生器)は共通モジュールを利用
アプリ画像
利用アーキテクチャ
- Flux
- Clean
- ReactivePrograming
全体的に
全体を通して気になっていること
- 1ファイルに集約するように実装したので、変数の参照スコープがスパゲッティになっている
Riotjs で気なったところ
- Rxjs の mixin の機能を用いているので、this のスコープが 実際の tag そのものになるので ぱっと見気持ち悪い。実際は一つのアーキテクチャを選択するので、tag ない記述するので変数の参照スコープは綺麗になるはずです
それぞれのアーキテクチャで
コードの成分は画像から確認してください
{Web}, {Sequencer} は共有モジュールに該当します
Flux
Clean
ReactivePrograming
Flux 考察
構造
ずる
- action creator, callback, change events store querises 周りは、ふわっとぼやかしました
気になったところ
- Dispatcher は、Singleton, 画面?機能?ドメイン?などどのスコープがいいのだろう
- action creator, store 周りは、クラス化するのが大数の実例になりそうな気がするけど、ファイル量産体制になるんのでやだなぁ
Riotjsなら単純に Riot.Observable を利用すれば、いいだけで Flux感はいらない気がした
animation, sequencer の View に関連しない所の扱いがカテゴライズされずに微妙な扱いになった
Clean 考察
構造
ずる
- Usecase Input Port / Interactor / Output port を個別に書くと、タイプ量が増えるので、Riot.Observable に集約して、trigger => input, on('xxx') => output+interactor な立ち位置で記述した
気になったところ
- ガッチガチにすると クラスファイル量産体制になるので 柔らか頭の人たちがいる場合でないと選択したくないなぁ
- 概念ごとに綺麗に分けられるので、Fluxより整理整頓したければ利用すればいいと思った
ReactivePrograming 考察
構造
気になったところ
- Rxjs でイベントのsubscriberを作成する場合、tagのイベントの中で関数を定義すると イベント毎にObservableを生成するので、切り出して作成が必要
ダメな例
var me = this;
me.clickObservable = undefined;
function onClick(event) {
me.clickObservable = Rx.Observable(function() {
// subscriber some thing
})
}
- subscriber の関数を生成する時に、tag のインスタンスが必要で mixin を利用すると参照できるタイミングが、今回だと initPanel のタイミングに絞られて、そこで subscribe() の関数を設定していて見た目がきもい感じになってしまった