Flux設計論
scala.jsの実用が真面目にペイされる環境を考えると、jsとscalaのアダプタ部分を考える俺と、scalaレベルで何ができて何ができてないか考える俺が二人いればプロダクションで成立しそう
— ガソリンの味 (@mizchi) 2015, 4月 28
Scala.jsが生きる場所、たとえば次のプロジェクトはウェブ版シムシティを作ることですって言われたら、ドメイン部分がピュアでかつ複雑になるのでScala.jsを選択するのはありだと思う
— ガソリンの味 (@mizchi) 2015, 4月 28
ドメインがピュアでかつ複雑、基本的にatljsが活かせる部分なので、人によってはpurescript選んでもよいわけだし
— ガソリンの味 (@mizchi) 2015, 4月 28
アダプタの書き方が altjs => js か js => altjsかで運用勘が結構変わる
— ガソリンの味 (@mizchi) 2015, 4月 28
FluxでReactとEventEmitter使った設計だと、ドメイン層の境界面はReactのルートとなるコンポーネントに引数渡す部分と、emitterで受ける側の二箇所に限定されるので、それさえ知ってればお互いがどういう実装であるか知る必要がないのが強い
— ガソリンの味 (@mizchi) 2015, 4月 28
なのでFluxフレームワークの責務を考えた時、ルートコンポーネントにドメイン層の現在のStateを渡す部分と、ActionCreator的なものでEmitterのpub/subを明示的に分離する部分に注力すべきでArdaはそれプラス画面遷移を表現したわけだけども
— ガソリンの味 (@mizchi) 2015, 4月 28
ActionCreatorって自分の理解だとemitterのpub/subを明示的に分離する機構であり、とはいえ生emitter見えたほうがbrowserifyした資産と組み合わせやすいのとルールが単純なのでモジュールが疎結合になるっていうのがある
— ガソリンの味 (@mizchi) 2015, 4月 28
ReactComponentはイベントをsubscribe出来るべきではなくて、Fluxで一周回してstateを受け取りたいんだけど、たまにしたくなる
— ガソリンの味 (@mizchi) 2015, 4月 28
まあ原則するべきではなくて裏側でこっそりやるぐらいならいいか、というやつ
— ガソリンの味 (@mizchi) 2015, 4月 28
@watilde CSS、型制約による嬉しさと型制約の煩わしさだと後者のほうが勝ちそう
— ガソリンの味 (@mizchi) 2015, 4月 28
CSSに型欲しい人たまにみるけど真面目に使いこなせるのVoQnぐらいでは
— ガソリンの味 (@mizchi) 2015, 4月 28