angularjsとfluxとriotjsと
TRANSCRIPT
AngularJSとFluxとRiotJSと
2015/10/28 GotandaJS # @mizuki_r
Profileaccount.
twitter: @mizuki_r github: ry_mizuki role.
フロントエンドエンジニア
tags.
AngularJS, RiotJS, Backbone,
hariko, angular-period, etc
Theme
• AngularJSで書いたアプリをFlux化した話
• Flux化したAngularJSアプリにRiotJS入れた話
AngularJSで書いたアプリをFlux化した話
What is Flux?
Flux’s architecture
https://facebook.github.io/flux/docs/overview.html
Flux’s architecture
• Facebookが提唱したアーキテクチャ
• データの流れを一方向に限定する
• Store, View, Dispatcherの責務がActionという単位で処理を回す
Flux’s architecture
https://github.com/facebook/flux/tree/master/examples/flux-todomvc/#structure-and-data-flow
Why Flux
Why Flux?• modelの管理に疲れた
• データ構造と責務分担の分類の考察
• 急なデータの変更、Viewの変更
• controllerでmodelを管理しがち
• modelとmodelの連携
• controllerの抽象化が雑に…
所謂MVCの運用には 高度な訓練と
高い意識が必要なのでは？
もっと低意識で運用したい！
I thought…
ぼくのかんがえたさいきょうの…• Dispatcherは自前でObserver定義 • ViewとActionCreator, Storeは一対
• ドメインの定義はViewにすべて移譲 • ActionCreatorは外部との連絡用
• API通信はngResourceをwrapしてrepositoryとして分離
• actionにする前にデータ整形を行うメソッドをかます
ぼくさいFlux arch
ぼくさいFlux arch
import * as action_creator from '../action-creators/example' import store from '../stores/example'
class ExampleCtrl { constructor ($scope) { this.onReceiveData = this.onReceiveData.bind(this) this.onDestroy = this.onDestroy.bind(this) store.addReceiveDataListener(this.onReceiveData) $scope.$on('$destroy', this.onDestroy) action_creator.init() } select () { action_creator.select() } onReceiveData () { this.data = store.getData() } onDestroy () { store.removeReceiveDataListener(this.onReceiveData) } }
angular.module('example').controller('ExampleCtrl', ExampleCtrl)
import dispatcher from '../dispatcher' import action_types from '../action-types' import injector from '../injector'
export function init () { dispatcher.handleViewAction({ type: action_types.INIT_EXAMPLE_VIEW, }) var Repository = injector.get('ExampleRepository') Repository.fetch().then((data) => { dispatcher.handleApiAction({ type: action_types.RECEIVE_EXAMPLE_DATA, data }) }) }
export function select () { dispatcher.handleViewAction({ type: action_types.SELECT_EXAMPLE_VIEW, }) var Repository = injector.get('ExampleRepository') Repository.post().then((data) => { dispatcher.handleApiAction({ type: action_types.POST_SELECT_EXAMPLE_DATA, data }) }) }
conclusion
• ViewをActionCreatorとStoreに抽象化できた
• コードが冗長になり、量が増えた
• 初期開発コストは高いが更新の手間などは減った
ViewをActionCreatorとStoreに抽象化できた
…あれ？
Angularじゃなくてもよくね？
Flux化したAngularJSアプリにRiotJS入れた話
What is RiotJS?
RiotJS
• Reactライクのユーザインタフェースライブラリ
• とっても小さい
• Virtual-DOM
• JavaScript in HTML
<todo>
<!-- layout --> <h3>{ opts.title }</h3>
<ul> <li each={ item, i in items }>{ item }</li> </ul>
<form onsubmit={ add }> <input> <button>Add #{ items.length + 1 }</button> </form>
<!-- logic --> <script> this.items = []
add(e) { var input = e.target[0] this.items.push(input.value) input.value = '' } </script>
</todo>
http://riotjs.com/ja/
ファイルサイズ
Reactの約1/19!
つまり…• 小さいし必要最小限の機能
• 細かいViewの制御なら十分なAPI
• 明示的な更新が可能なI/F
• Component系なので最小限の変更範囲
• 書きやすそうなJSX
Why is RiotJS?
AngularJSへの不満…
• $applyが重い
• 暗黙的な$digestの管理が辛い
$applyが遅い• 式を受け取りViewを更新するかを判定
• 更新する場合は`$scope.$digest()` を実行
• $http, $timeoutなどのAPIが内部的に利用
• 登録されているすべてのリスナを評価する
• 遅い評価式を登録してしまうと更新のたびに…
暗黙的な$digestが辛い• $http, $timeoutなどAPIが暗黙的に発行する
• 発行しないAPIもある
• 自前で作った機能は$scope.$apply等が必要
• たまたまうまく更新がされるケース
• digest中にdigestを発行すると死ぬ
つまり…• 特定のView以下で更新したい
• 短いサイクルでの更新
• 毎秒すべてのViewを評価してどうする
• 明示的に更新したい
• 必要ないところで評価されても
• 更新したいタイミングは僕らが決めたい
Angular with Riot
RiotJSの役割• 末端のViewの更新サイクルの管理
• 毎秒更新が発生するもの
• ホバーなどサイクルが短いもの
• ユーザアクションのハンドルと他のViewとの連携はFluxベースのアーキテクチャで吸収
• RiotからAngularのViewは参照しない
directive
angular.module('example', []).directive('todo', function () { return function () { riot.mount('todo') } })
directive化することで、templateから参照できる。
outside injector
exports.get = function (name) { return angular.element(document).injector().get(name) }
injectorをAngularの管理外から参照できるように
入れてみた結果• 「遅い」と言われてた部分が解消(体感的に)
• ぶっちゃけRiotJSが早いわけじゃない
• むしろ状況次第ではAngularより遅い
• $digest漏れや$applyの遅延による「遅く見える」が減少した
• RiotJS、以外と書きやすい
Conclusion
Conclusion• FluxによるViewの抽象化事例を紹介
• Viewの単位でコードを管理できるので、追加・更新・削除が思いの外簡単になった
• でもコード量は増えた
• AngularJSとRiotJSの共存事例を紹介
• 目に見えて反応が違った
• RiotJSは必要最小限で使う分にはかなり使い勝手良い
• 個人的にはRiotJSXはもっと使って行きたい
Next Generation• Fluxでの責務分担のあり方をもうちょっと考えたい
• いずれこれは二層式に集約されていくのだろうなと
• ServiceWorker上で扱えるレベルのロジックの抽象化
• メインスレッドを綺麗にしてUIのパフォーマンスあげたい
ご清聴ありがとうございました