これは？

社内発表のコードの反省会/説明/言い訳 用です。主に下記になります。

• きになる点
• 省いて（ズル）いる点

やったこと

• 同じアプリケーションをそれぞれのアーキテクチャを用いて作成
• xhr , アニメーション , シーケンサー(イベント発生器)は共通モジュールを利用

アプリ画像

利用アーキテクチャ

• Flux
• Clean
• ReactivePrograming

全体的に

全体を通して気になっていること

• １ファイルに集約するように実装したので、変数の参照スコープがスパゲッティになっている

Riotjs で気なったところ

• Rxjs の mixin の機能を用いているので、this のスコープが 実際の tag そのものになるので ぱっと見気持ち悪い。実際は一つのアーキテクチャを選択するので、tag ない記述するので変数の参照スコープは綺麗になるはずです

それぞれのアーキテクチャで

• コードの成分は画像から確認してください

• {Web}, {Sequencer} は共有モジュールに該当します

Flux

app-flux.js

Clean

app-clean.js

ReactivePrograming

app-rp.js

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() の関数を設定していて見た目がきもい感じになってしまった

参考

• 社内発表用 擬人化アーキテクチャ
• アーキテクチャ比較にゃ 2016 概要編