穏健AngularJS 〜 あいつはフレームワーク

Transcript

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

2. Hello! • 奥野 賢太郎 はちさん armorik83 • ng-kyoto代表 • 業務でAngularJSやったりします

   • 趣味ではAngular 2やってます • あさってから東京
 ダンボールの山の中でこの資料を書いた

3. あるng-kyotoミーティング

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

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

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

7. ＿人人人人人人人人人＿ ＞　AngularJSやれよ　＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

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

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

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

11. そもそも過激って何 • 公式Docsが書いていないことを積極的に採り入れる • 他のライブラリ、フレームワークの流儀の
 影響を受けすぎる • Angular 2の登場と移行について恐れたあまり
 AngularJSとの距離を取りたがる

    • 自分がやりやすいというだけで、万人受けしない手法を
 好んで試す

12. だいたいこいつ

13. 穏健に行こう • 何が過激で、何が穏健かよく考えた上で、
 本日のノウハウ集とします • 対象者： AngularJS経験が「ほどほど〜そこそこ」ある方 • 発表内容が過激と感じたら、すかさずハッシュタグ #ng_kyoto

    で「まだ過激やぞ！」とお叱りください • マサカリが必要と感じたら即座に放ってください

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

15. • Reactと合わせて広まったFacebook Fluxアーキテクチャ • 8月になってから盛んにRedux! Redux!と騒がれる • このデータフローをAngularJS上で$broadcastとclassを 組み合わせて構築 •

    83曰く「AngularJSのDirectiveとロジックの分離や
 実装箇所の見通しがついて最高！」
 
 詳しくは [イベント駆動AngularJS] [検索]

16. 過激

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

18. • Directive中心に設計しつつ、ストアとロジックをServiceに • ServiceはSingleton、言い換えると、これ自体が巨大グローバル変数
 子DirectiveがバラバラにDIしない • 親 (Root) Directiveが責任を持ってDI
 子DirectiveからServiceを操作したい場合は$rootScope.$broadcast()

    • Serviceは$rootScope.$on()によってイベントを受ける • 子DirectiveはbindToControllerを用いてインタフェースを備え
 親は必要な値を子に渡す • 子は渡された値のみをViewに利用する

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

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

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

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

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

23. 過激

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

25. • たしかにテスト時にモック化が可能ならばその機構は
 なんでもいいが、それはオレオレになっていないか • AngularJSは最初からDIが備わっているので、チーム内での学習 コスト分散を防ぐためにも、用意された機構は全員で正しく使う • テストはKarmaよりMochaのみで完結した方が実行だけなら短時間 • 短時間のテストを優先して歪な機構を生み出すか、


    多少遅くても公式Docsの通りKarma + inject()を用いるか • どうせCIでも回すのだからKarmaのブラウザ起動コストは
 無視できるレベルという見方もできる

26. 過激3. $scopeは全廃

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

28. 過激

29. 穏健3. $scopeは削減

30. • Angular 2が$scopeを廃止するのは事実 • 長期的に活用を見越しているならば減らす方向に
 手入れするのが吉 • ui-routerを使っている場合、特に起こりうるのがGC漏れ • $broadcast,

    $onのイベントをすでに多階層で利用して
 いる場合、安易にすべての$scopeを置き換えると$destroyに よる適切なイベントの破棄がされずバグの温床 • ルーティング切り替えでどんどんリスナが溜まって処理が
 重くなっていく…（その節はご迷惑おかけしました）

31. • 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); } }

32. 穏健

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

34. これって？ ？ • Q1. npmとBrowserifyを組み合わせるのはですか？ • A1. です
 AngularJSは1.3の途中から正式にCommonJSをサポートし
 npm

    installも可能 • ただし記述には派閥があるっぽい • 各ソースでrequire('angular')する派　　の参加した案件
 旧ソースを引き継ぐと、こうなりがち • angular.moduleを細かく作って各ソースでexportする派
 新規案件ならこの手法も採り入れやすい、OSSにも採用例あり

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

36. これって？ ？ • Q2. ui-routerを使うのはですか？ • A2. です
 公式もこのサードOSSは十分認識しており、積極的に使って問題ありません •

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

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

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

    まだ早い • しっかり整うまで待とう • 一旦忘れよう • 詳しくは先週
 "Angular 2@Grand-Frontend-Osaka 2015 Summer"で話した
 speakerdeck.com/armorik83/angular-2-at-grand-frontend-osaka-2015-summer

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

40. Have a nice 穏健!