Slide 1

Slide 1 text

穏健AngularJS あいつはフレームワーク Aug 30, 2015 @ ng-kyoto Angular Meetup #2

Slide 2

Slide 2 text

Hello! • 奥野 賢太郎 はちさん armorik83 • ng-kyoto代表 • 業務でAngularJSやったりします • 趣味ではAngular 2やってます • あさってから東京
 ダンボールの山の中でこの資料を書いた

Slide 3

Slide 3 text

あるng-kyotoミーティング

Slide 4

Slide 4 text

あるng-kyotoミーティング AngularJSのアーキテクチャにFlux合わせたら
 いい感じだった

Slide 5

Slide 5 text

AngularJSのアーキテクチャにFlux合わせたら
 いい感じだった _likrが入力中… あるng-kyotoミーティング

Slide 6

Slide 6 text

AngularJSのアーキテクチャにFlux合わせたら
 いい感じだった AngularJS使うならAngularJSやれよ あるng-kyotoミーティング

Slide 7

Slide 7 text

_人人人人人人人人人_ > AngularJSやれよ <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

Slide 8

Slide 8 text

AngularJSやってなかった…? • 今まで作ってきた資料は間違っていた…? • Angular 2の登場に狼狽しすぎたのか…? • AngularJSをAngularJSらしく使うとは一体…?

Slide 9

Slide 9 text

原点に帰る • 1.0が出た時の原点に、一旦帰ろう • Reactもなければ、Babelもなかった時代 • AngularJSはBackbone.jsやKnockout.jsと
 同じ土俵で戦ったJavaScriptフレームワーク

Slide 10

Slide 10 text

チーム開発に参加 • ちょうどそんな時期に、某社某サービスの案件に参加
 けっこう大規模 • AngularJSの「あいつはフレームワーク」感を
 存分に味わえるチーム開発の現場 • 受託でチームに参入して過激なことなど
 やってはいけない!

Slide 11

Slide 11 text

そもそも過激って何 • 公式Docsが書いていないことを積極的に採り入れる • 他のライブラリ、フレームワークの流儀の
 影響を受けすぎる • Angular 2の登場と移行について恐れたあまり
 AngularJSとの距離を取りたがる • 自分がやりやすいというだけで、万人受けしない手法を
 好んで試す

Slide 12

Slide 12 text

だいたいこいつ

Slide 13

Slide 13 text

穏健に行こう • 何が過激で、何が穏健かよく考えた上で、
 本日のノウハウ集とします • 対象者: AngularJS経験が「ほどほど〜そこそこ」ある方 • 発表内容が過激と感じたら、すかさずハッシュタグ #ng_kyoto で「まだ過激やぞ!」とお叱りください • マサカリが必要と感じたら即座に放ってください

Slide 14

Slide 14 text

過激1. AngularJSでも Fluxやってみた

Slide 15

Slide 15 text

• Reactと合わせて広まったFacebook Fluxアーキテクチャ • 8月になってから盛んにRedux! Redux!と騒がれる • このデータフローをAngularJS上で$broadcastとclassを 組み合わせて構築 • 83曰く「AngularJSのDirectiveとロジックの分離や
 実装箇所の見通しがついて最高!」
 
 詳しくは [イベント駆動AngularJS] [検索]

Slide 16

Slide 16 text

過激

Slide 17

Slide 17 text

穏健1. Serviceと $broadcastベースで

Slide 18

Slide 18 text

• Directive中心に設計しつつ、ストアとロジックをServiceに • ServiceはSingleton、言い換えると、これ自体が巨大グローバル変数
 子DirectiveがバラバラにDIしない • 親 (Root) Directiveが責任を持ってDI
 子DirectiveからServiceを操作したい場合は$rootScope.$broadcast() • Serviceは$rootScope.$on()によってイベントを受ける • 子DirectiveはbindToControllerを用いてインタフェースを備え
 親は必要な値を子に渡す • 子は渡された値のみをViewに利用する

Slide 19

Slide 19 text

• $emitにする必要はないのかとよく聞かれる
 これは親方向に限られたイベント伝播、設計変更に弱い • パフォーマンス面で言っても多量のng-repeatで
 遅くなる問題に比べると誤差 • One-time bindingは積極的に活用しよう


{{::name}}

• 一度レンダリングしたあと変える予定のない値は
 $digest loopの走査対象から外すことで高速化

Slide 20

Slide 20 text

過激2. AngularJSの
 DIなんて使わない

Slide 21

Slide 21 text

• DIはモック化を容易にし、テスト可能性を上げるための機構 • 83曰く「モックテストが実現できればAngularJSが備えて
 いるDIは使わなくてもいいんじゃね」 • proxyquireマジオススメ

Slide 22

Slide 22 text

• DIはモック化を容易にし、テスト可能性を上げるための機構 • 83曰く「モックテストが実現できればAngularJSが備えて
 いるDIは使わなくてもいいんじゃね」 • proxyquireマジオススメ • オススメでもなかった…
 あれは大規模になればなるほど、パス管理でハマってつらい

Slide 23

Slide 23 text

過激

Slide 24

Slide 24 text

穏健2. きっちりDI
 テストはKarmaで

Slide 25

Slide 25 text

• たしかにテスト時にモック化が可能ならばその機構は
 なんでもいいが、それはオレオレになっていないか • AngularJSは最初からDIが備わっているので、チーム内での学習 コスト分散を防ぐためにも、用意された機構は全員で正しく使う • テストはKarmaよりMochaのみで完結した方が実行だけなら短時間 • 短時間のテストを優先して歪な機構を生み出すか、
 多少遅くても公式Docsの通りKarma + inject()を用いるか • どうせCIでも回すのだからKarmaのブラウザ起動コストは
 無視できるレベルという見方もできる

Slide 26

Slide 26 text

過激3. $scopeは全廃

Slide 27

Slide 27 text

• Angular 2は$scopeを廃止する • だったらそれを見越して今から$scopeは全廃だ! • 一律でclass構文とthisにするぞ!

Slide 28

Slide 28 text

過激

Slide 29

Slide 29 text

穏健3. $scopeは削減

Slide 30

Slide 30 text

• Angular 2が$scopeを廃止するのは事実 • 長期的に活用を見越しているならば減らす方向に
 手入れするのが吉 • ui-routerを使っている場合、特に起こりうるのがGC漏れ • $broadcast, $onのイベントをすでに多階層で利用して
 いる場合、安易にすべての$scopeを置き換えると$destroyに よる適切なイベントの破棄がされずバグの温床 • ルーティング切り替えでどんどんリスナが溜まって処理が
 重くなっていく…(その節はご迷惑おかけしました)

Slide 31

Slide 31 text

• Angular 2に移行する気が無いのなら、$scopeの件は
 「一切気にしない」のもひとつの手 • ただし$scope削減はTypeScriptやES2015の利用時に
 記述がシンプルになり有用なので、十分検討の価値がある • controller as構文やbindToControllerも活用する function tabs($scope){ var panes = $scope.panes = []; $scope.select = function(pane) { angular.forEach(panes, function(pane) { pane.selected = false; }); pane.selected = true; } this.addPane = function(pane) { if (panes.length == 0) $scope.select(pane); panes.push(pane); } } class Tabs { constructor() { this.panes = []; } select(pane) { angular.forEach(this.panes, (_pane) => { _pane.selected = false; }); pane.selected = true; } addPane(pane) { if (panes.length == 0) { this.select(pane); } this.panes.push(pane); } }

Slide 32

Slide 32 text

穏健

Slide 33

Slide 33 text

これって? ? • Q1. npmとBrowserifyを組み合わせるのはですか?

Slide 34

Slide 34 text

これって? ? • Q1. npmとBrowserifyを組み合わせるのはですか? • A1. です
 AngularJSは1.3の途中から正式にCommonJSをサポートし
 npm installも可能 • ただし記述には派閥があるっぽい • 各ソースでrequire('angular')する派  の参加した案件
 旧ソースを引き継ぐと、こうなりがち • angular.moduleを細かく作って各ソースでexportする派
 新規案件ならこの手法も採り入れやすい、OSSにも採用例あり

Slide 35

Slide 35 text

これって? ? • Q2. ui-routerを使うのはですか?

Slide 36

Slide 36 text

これって? ? • Q2. ui-routerを使うのはですか? • A2. です
 公式もこのサードOSSは十分認識しており、積極的に使って問題ありません • ただしui-viewネストには細心の注意を払った方がいい • 設計変更、値渡し、$rootScopeと$scopeの破棄タイミング等々
 気にすることが一気に増えてしまう
 + チーム内への十分な周知やDocs整備も必要となってくる • プロトタイピングや初期開発でいきなり根深く組み込んでしまうと
 忙しい時期に辛くなってくるかも

Slide 37

Slide 37 text

これって? ? • Q3. Angular 2とAngularJSは組み合わせられるそうですが、ですか?

Slide 38

Slide 38 text

これって? ? • Q3. Angular 2とAngularJSは組み合わせられるそうですが、ですか? • A3. です • まだ早い • しっかり整うまで待とう • 一旦忘れよう • 詳しくは先週
 "Angular 2@Grand-Frontend-Osaka 2015 Summer"で話した
 speakerdeck.com/armorik83/angular-2-at-grand-frontend-osaka-2015-summer

Slide 39

Slide 39 text

AngularJSを用いたチーム開発で
 フレームワークとしての本領を発揮

Slide 40

Slide 40 text

Have a nice 穏健!