2015/3/7 に[MSakamaki](https://github.com/MSakamaki)氏に声を掛けられれて一緒に AngularJS ES6 リファクタソンを開催しました。

内容は参加者が 2〜3 人のチームに分かれて ES5 で書かれた Angular1.3 ベースの Web アプリを、ES6 でリファクタするという企画です。
ES5 のコードの中にクソコードを仕込んでおいて、ついでにリファクタしてくれるかなーなんて思いながら主催側ですが、一緒にリファクタして結構楽しかったです。

Angular1.3 を ES6 でリファクタするポイントや、書き換えてみての所感とかまとめようと思います。  
(注 今回のコードは実験的な試みです。プロダクションコードに適用するかは自己責任でお願いします。)

[AngularJS ES6 リファクタソン - AngularJs Japan User Group | Doorkeeper](https://angularjs-jp.doorkeeper.jp/events/21008)



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-refactor.png)

## Angular1.X 系は ES6 と相性が悪い？？

始めにやってみた感じの所感を先に紹介すると、**ES6 の新機能は非常に魅力的だけど、Angular1.X 系の DI との組み合わせ(特に Modules)が、非常に相性が悪い** と思いました。
残念な部分も含めて ES6 へのリファクタのポイント紹介します。

## 環境周り

ES6 にはまだブラウザ上で動作しない仕様もあるため、Babel を使って ES6 で書いたコードを ES5 へコンパイルしました。また、最近 Babel とセットで使われることが多い jspm を利用ました。

- [Babel · The transpiler for writing next generation JavaScript](https://babeljs.io/)
- [jspm.io - Frictionless Browser Package Management](http://jspm.io/)

リファクタソンの課題はこちらです。

- [MSakamaki/AngularEs6Son](https://github.com/MSakamaki/AngularEs6Son)

こちらがリファクタ  ソンの内容を持ち帰って、私が書き直してみたコードです。今回紹介するコードはこちらのリポジトリにあります。全体を見たい場合はこちらを見てください。

- [mitsuruog/angular-es6](https://github.com/mitsuruog/angular-es6)

## controller

contorller は ES6 の class を使って置き換えます。

(client/app/list/list.controller.js)

```js
export default class ListController {
  constructor(BeanService, RegionsService) {
    this.beans = [];
    this.regions = [];
    this.beanService = BeanService;
    this.regionsService = RegionsService;
    // APIアクセス部分
    // Arrow Functionはthisを固定してくれるので、
    // promiseの中がthisと書けて非常に嬉しい
    this.beanService.query().$promise.then((data) => (this.beans = data));
    this.regionsService.query().$promise.then((data) => (this.regions = data));
  }
  // template側で利用する機能
  delete(id) {
    this.beanService
      .delete({
        id: id,
      })
      .$promise.then(() => {
        this.beanService.query().$promise.then((data) => (this.beans = data));
      });
  }
}
// Strict DI
ListController.$inject = ["BeanService", "RegionsService"];
```

class 内で再利用する Object は一旦`this`に格納します。
`this`の利用頻度が多いですが、普段`controllerAs`で contorller を利用している人にとっては、あまり違和感なのではないでしょうか。
module への登録は次のように行います。

(client/app/app.js)

```js
import ListController from "./list/list.controller";

export var app = angular.module("Es6App", ["ui.router"]);

// controllers
app.controller(ListController.name, ListController);
```

このあたりまでは ES6 の Arrow Functions・Classes・Modules などの新機能を使って Angular1.X 系でもいけるんじゃないかと思います。わたしにもそんなこと思っていた時期がありました。

ES6 の Class と Arrow Functions は本当にいいですね。

## factory

factory も contoller と同様に class を使って置き換えます。

(client/dataservices/beans/beans.service.js)

```js
export default class BeanService {
  constructor($resource) {
    return $resource(
      "http://localhost:8000/api/beans/:id",
      {
        id: "@id",
      },
      {
        update: {
          method: "PUT",
        },
      }
    );
  }
}
// Strict DI
BeanService.activate.$inject = ["$resource"];
```

module への登録は次のように行います。

(client/dataservices/index.js)

```js
import BeanService from "./beans/beans.service";

export var app = angular.module("Es6AppDataServices", ["ngResource"]);

app.factory("BeanService", ($resource) => new BeanService($resource));
```

module 登録の際に factory Class をインスタンス化する必要があります。さらに DI の注入がある場合は、依存関係のモジュールを渡さなければなりせん。
Angular1.X 系の DI の仕組みは、ES6 の Modules とは相性が悪いようです。そこで、Class のインスタンスを返す static な function を追加して次のように改善してみました。

(client/dataservices/beans/beans.service.js)

```js
export default class BeanService {

  constructor($resource) {
    ...
  }

  static activate($resource){
    BeanService.instance = new BeanService($resource);
    return BeanService.instance;
  }

}
// Strict DI
BeanService.activate.$inject = ['$resource'];
```

これで module への登録は少しスッキリします。

(client/dataservices/index.js)

```js
...

app.factory('BeanService', BeanService.activate);
```

## filter

filter も同様に class で置き換えます。

(client/filters/regionName/regionName.filter.js)

```js
export default class regionName {
  constructor() {
    return (input, regions) => {
      let regionName = "";
      angular.forEach(regions, function (region) {
        if (region.id === input) regionName = region.name;
      });
      return regionName;
    };
  }

  static activate() {
    regionName.instance = new regionName();
    return regionName.instance;
  }
}
```

module の登録は factory と一緒なので省略します。

## directive

directive も同じです。

(client/components/amountLabel/amountLabel.directive.js)

```js
export default class amountLabel {
  constructor() {
    // directiveの設定系
    this.templateUrl = "components/amountLabel/amountLabel.html";
    this.restrict = "EA";
    this.scope = {
      amount: "=",
    };
  }

  link(scope, element, attrs) {
    if (scope.amount > 1000) {
      scope.styleClass = "text-info";
    } else if (scope.amount <= 1000 && scope.amount > 500) {
      scope.styleClass = "text-success";
    } else if (scope.amount <= 500) {
      scope.styleClass = "text-danger";
    }
  }

  static activate() {
    amountLabel.instance = new amountLabel();
    return amountLabel.instance;
  }
}
```

module の登録は factory と一緒なので省略します。

## config

Config や router も ES6 の Class で置き換えてみます。

(client/app/app.config.js)

```js
export default class AppConfig {
  constructor($locationProvider) {
    // アプリ共通の設定系
    $locationProvider.html5Mode(true);
  }

  static activate($locationProvider) {
    AppConfig.instance = new AppConfig($locationProvider);
    return AppConfig.instance;
  }
}
// Strict DI
AppConfig.$inject = ["$locationProvider"];
```

(client/app/app.route.js)

```js
export default class AppRouter {

  constructor($stateProvider, $urlRouterProvider) {

    $urlRouterProvider.otherwise('/list');
    $stateProvider.state('app', {
      abstract: true,
      url: '/#',
      template: `<div ui-view="header"></div>
        <div ui-view="contents" class="main"></div>
        <div ui-view="footer"></div>`
    })

	...

  }

  static activate($stateProvider, $urlRouterProvider) {
    AppRouter.instance = new AppRouter($stateProvider, $urlRouterProvider);
    return AppRouter.instance;
  }

}
// Strict DI
AppRouter.$inject = ['$stateProvider', '$urlRouterProvider'];
```

アプリのトップレベルの module への最終的な登録はつぎのとおりです。

(client/app/app.js)

```js
import angular from "angular";
import "angular-ui-router";

import "../components/index";
import "../dataservices/index";
import "../filters/index";
import AppConfig from "./app.config";
import AppRouter from "./app.route";
import ListController from "./list/list.controller";

export var app = angular.module("Es6App", [
  "ui.router",
  "Es6AppFilters",
  "Es6AppDataServices",
  "Es6AppComponents",
]);
// 設定系
app.config(AppConfig.activate);
app.config(AppRouter.activate);
// controllers
app.controller(ListController.name, ListController);
```

## 課題

とりあえず ES6 に置き換えることはできそうですが、テスト周りについての変更点については、まだ検証できてません。
個人的にはテストの spec が ES6 で書けるだけでも嬉しいです！！

- Angular1.X 系で良かった、テスタビリティがどれくらい犠牲にされているか。
  - ngMock
  - カバレッジ測定
  - E2E(protoractor)
- そもそもこの書き方でいいのか・・・

## さいごに

今や最も優れている(？)Angular1.X 系。
2 年後くらいに ES6 が主流になったとき、今の Backbone を見る時に感じるものと同じ感覚を覚えるのではないかと思いました。
また、来年には Angular2 が来ると言われているのですが、1.X 系とは全く別物なんですよねー(白目)。

にしても、いつになったらフロントエンド開発のデファクトが定まるのか、まだまだ JS フレームワークの長い旅は続きそうです。

### 参考

- [Using ES6 with Angular today](http://blog.thoughtram.io/angularjs/es6/2015/01/23/exploring-angular-1.3-using-es6.html)
- [Exploring ES6 Classes In AngularJS 1.x](http://www.michaelbromley.co.uk/blog/350/exploring-es6-classes-in-angularjs-1-x)
- [Writing AngularJS Apps Using ES6](http://www.sitepoint.com/writing-angularjs-apps-using-es6/)
- [Using ES6 Modules with AngularJS 1.3 — GoCardless Blog](https://gocardless.com/blog/es6-angular/)
- [gocardless/es6-angularjs](https://github.com/gocardless/es6-angularjs)
- [lukehoban/es6features](https://github.com/lukehoban/es6features)
- [yoheiMune/es6features(上の日本語  訳)](https://github.com/yoheiMune/es6features)

Angular1.X系をES6で書いてみたらちょっと残念だった話〜AngularJS ES6リファクタソンを終えて〜

タイトルの通りです。割と遭遇している人いるんじゃないかなと勝手に想像しているんですが、あまり情報ないので書いてみます。

ユースケース的には、WebAPI アクセスで日付を JSON シリアライズしたものを受け取って、input[type=date]の ng−model に直接データバインドするような想定です。



## サンプルコード

(適当に書いているので動かなかったらすみません。雰囲気だけでも。)

WebAPI 側から JSON データ

```json
{
  "id": 1,
  "name": "ググレカス",
  "createdAt": "2015-02-05T00:00:00.000Z"
}
```

AngularJS の DataService 的コード(今回は factory)

```js
angular.module("app").factory("ggrks", function ($resource) {
  return $resource("/api/ggrks");
});
```

AngularJS の Controller

```js
angular.module("app").controller("ggrksController", function ($scope, ggrks) {
  // 初回データアクセス
  ggrks.query(function (data) {
    $scope.ggrks = data;
  });
});
```

AngularJS のテンプレート

```html
<input type="date" ng-model="ggrks.createdAt" />
```

このまま実行すると、このようなエラーが発生します。しょぼーん。

```sh
Error: [ngModel:datefmt] Expected `2015-02-05T00:00:00.000Z` to be a date
 ....
```

## input[type=date]にセットする model は Date 型でなければならない

公式ドキュメントをよく見ると書いてました。有効な ISO-8601 フォーマット(yyyy-MM-dd)と書いてますが、Javascript 的には Date 型に Parse してセットしなければならないようです。

[AngularJS: API: input[date]](https://docs.angularjs.org/api/ng/input/input%5Bdate%5D)

WebAPI から受け取る日付は JSON シリアライズされているので、いちいち Date 型に Perse しなければならないのか。。。本当に面倒くさい。

## 現在のベターな回答

いちいち Controller にて Parse するのはナンセンスなので、DataService(factory)で Parse することにしました。

ビルトインの`$resource`サービスには、受け取ったレスポンスを変形させて後続処理に渡す`transformResponse`があるので、今回はこちらを使ってみました。  
(Backbone.Model や Collection の`parse`相当です。)

変更後の DataService 的コード

```js
angular.module("app").factory("ggrks", function ($resource) {
  return $resource("/api/ggrks", {
    query: {
      transformResponse: transformResponse,
    },
  });

  // 受け取ったJSONをObjectにParseする
  function transformResponse(data) {
    data = angular.fromJson(data);
    data.createdAt = new Date(data.createdAt);
    return data;
  }
});
```

無理やり感がはんぱないですが、、、これで無事、input[type=date]に対して日付型をデータバインドさせることができました。  
[W3C の仕様](http://www.w3.org/TR/html5/forms.html#date-state-(type=date)でも、日付として有効な文字列は自動的にParseされるようですし、できればフレームワーク側で判断してPerseして欲しいところですが。。。

これより良いやり方ご存知の方いらっしゃいましたら、ぜひ教えてください。

### 参考文献

- [javascript - How to set right date format for editable-date - Stack Overflow](http://stackoverflow.com/questions/26825433/how-to-set-right-date-format-for-editable-date)
- [javascript - Why is my date input field in AngularJS throwing type error? - Stack Overflow](http://stackoverflow.com/questions/26853173/why-is-my-date-input-field-in-angularjs-throwing-type-error)
- [Why is my date input field in AngularJS throwing type error? | Arianna](http://hiteshtwo.org/arianna/2015/01/20/why-is-my-date-input-field-in-angularjs-throwing-type-error/)

少し古いですがこちらに書かれている、dateInput 用のカスタム directive を作成する方法が良さそうな気がします。(未検証)

[javascript - Angular.js and HTML5 date input value -- how to get Firefox to show a readable date value in a date input? - Stack Overflow](http://stackoverflow.com/questions/18061757/angular-js-and-html5-date-input-value-how-to-get-firefox-to-show-a-readable-d)

AngularJSでinput[type=date]にデータバインドしようとしてError: [ngModel:datefmt]で怒られて困っている人向けの小ネタ

最近は、WebAPI や AWS のようなクラウドサービスが普及してきて、バックエンドのサーバーがなくても、Web サービスが公開できるようになってきました。

今回は AWS の**S3 にある Static Website Hosting 機能**を使って AngularJS で作成した SPA(Single page application)をホスティングさせてみました。

割と S3 でのサイト公開は簡単なので楽勝かと思いきや・・・  
いろいろまじめに考えると手こずるものですね。



## S3 での SPA 公開

S3 でのサイト公開は非常に簡単です。次の 3 ステップで即公開できます。  
(「S3 サイト公開」などで検索するといくつか記事がヒットすると思いますので参考にしてください。)

- S3 上に Bucket を作成する。
- AngularJS で作成した SPA をアップロードする。
- Bucket の Static Website Hosting を ON にする。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-1.png)

Static Website Hosting を ON にすることでアクセス可能な URL が取得できます。  
アクセスした際に「`AccessDenied`」エラーになる場合は、アップロードしたファイルの`Permissions`が**Everyone アクセス可能**になっていないことが多いです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-2.png)

しかし、この**Everyone アクセス可能**状態はあまりいい状態ではありませんので、CloudFront を利用します。  
(後で紹介しますが、S3 は CloudFront 経由のアクセスのみ有効にする設定を推奨します。)

> S3 の Everyone アクセス可能は Apache の設定漏れで、ファイル一覧が見えてしまっている感覚に似ていて落ち着きません w

他にも、S3 で公開した場合に問題になりそうな部分について紹介します。

## S3 での SPA 公開で問題になりそうなところ

S3 の Static Website Hosting 機能はお手軽で非常に魅力を感じるのですが、Web アプリケーションを想定した場合、次のような問題がありそうです。

- アクセスを`HTTPS`に限定できない。
- URL に「`/`」を指定した場合、S3 上のフォルダを参照してしまいエラーとなる。(結果「`/index.html`」まで含める形に・・・)
- 「`/`」以外の URL(「/hoge」とか)でアクセスした場合に`403(access denied)`エラー(2015/01/20 追記)
- 他にもあった気がするが、忘れた。

という訳で S3 のみのお手軽ホスティングは、コーポレートサイトのような静的コンテンツ向きな気がします。

## CloudFront の利用

そこで利用するのが CloudFront です。いろいろ探していたら、こちらの記事が参考になりました。ありがとうございます！

[[CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/cloudfront-s3-origin-access-identity/)

手順としては次のような形です。

- CloudFront 上に Distributions を作成
- Origin Domain Name に S3 の Bucket を指定
- Restrict Bucket Access で「Yes」を設定して S3 へのアクセスを制限

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-3.png)

これで CloudFront 経由で S3 へアクセスすることができますが、SPA をホスティングするに当たって追加で以下の設定をしました。

### General > Default Root Object

`Default Root Object`に「index.html」を設定します。これで「`/`」でアクセスした際に、エラーにならず「`index.html`」を呼び出すことができます。

しかも、デフォルトの(\*.cloudfront.net)ドメインであれば SSL 証明書までついてきます。  
まじで至れり尽くせりです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-5.png)

### Behaviors > Viewer Protocol Policy

新しい Behavior を作成して`Viewer Protocol Policy`にて`Redirect HTTP to HTTPS`を選択します。これで HTTP でアクセスされた場合に、HTTPS にリダイレクトすることが可能です。  
(あまりこだわりなければ`Path Pattern`は`Default (*)`1 つで事足りるはず。)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-4.png)

## CloudFront 利用上の注意点

CloudFront を利用すると幸せになれるのですが、1 点注意点があります。それは**キャッシュ**です。

CloudFront の本質は CDN なので、コンテンツをキャッシュします。しかもデフォルトでは**24h キャッシュを保持**するので、S3 上にアップロードしたファイルは最大 24h 変更されません。

### Invalidations を利用して Cache をクリア

CloudFront には Invalidations というキャッシュクリアをする仕組みがあるので、これを使って CloudFront に対してキャッシュのクリアを指示します。  
(ただ、5〜10 分くらいかかります。リアルタイムではないです。)

CloudFront で Distributions を選択すると「`Invalidations`」というタブがあるので、ここで「`Create Invalidation`」ボタンをクリックします。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2015/angular-s3-cloudfront-6.png)

クリアするファイルを指定する必要があるので、例えば「`/index.html`」とか入力します。  
私の場合、フロントのリソースは結合＆minify＆バージョニングして最適化してしまうので、普段は`index.html`だけで十分です。

あとはキャッシュがクリアされるまで気長に待ちましょう。

## まとめ

「S3 ＋ CloudFront」を使うことでお手軽に AngularJS で作成した Web アプリケーションをホスティングすることができました。しかも勝手にスケールするし、クラウドサービス偉大過ぎます。

### しかし、上には上がいる！

今回の「S3 ＋ CloudFront」はまだ**大関**構成なようですね。個人的には頑張ったと思うのですが。。。orz  
こちらの記事を読むと、この上の「S3 ＋ CloudFront ＋ Route53」**横綱**構成があるようです。

[AWS における静的コンテンツ配信パターンカタログ（アンチパターン含む） ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/static-contents-delivery-patterns/)

もっと稽古します。

> (2015/01/20 追記)  
> `/`以外の URL でアクセスした場合に`403(access denied)`エラーになるのですが、CloudFront Distributions の Error Pages 設定で、403 エラーの場合のエラーページを`/index.html`にすることで回避することができましたー。  
> うぇーーーーい！！って無理矢理感が半端ない w

AngularJSで作ったSPAをAWS上の「S3＋CloudFront」でお手軽ホスティングして、クラウドサービスってやっぱ素晴らしいなと思った話

小ネタです。  
いつも angular の controller を使うときは`ui-router`から`controllerAs`して使うことが多いですが、
controllerAs 仕様にした controller をユニットテストする際、少しハマったのでそのあたりを紹介します。



テストコードは angular 本家の[PhoneCat チュートリアル](https://docs.angularjs.org/tutorial)のものを利用します。

`controllerAs`仕様にカスタムした controller

contorller.js

```js
(function () {
  "use strict";

  angular.module("phonecatApp").controller("PhoneListCtrl", PhoneListCtrl);

  function PhoneListCtrl() {
    var vm = this;
    vm.phones = [
      {
        name: "Nexus S",
        snippet: "Fast just got faster with Nexus S.",
        age: 1,
      },
      {
        name: "Motorola XOOM™ with Wi-Fi",
        snippet: "The Next, Next Generation tablet.",
        age: 3,
      },
      {
        name: "MOTOROLA XOOM™",
        snippet: "The Next, Next Generation tablet.",
        age: 2,
      },
    ];
  }
})();
```

こちらがテストコード。

controllersSpec.js

```js
"use strict";

describe("Controller: PhoneListCtrl", function () {
  // load the controller's module
  beforeEach(module("phonecatApp"));

  var MainCtrl, scope;

  // Initialize the controller and a mock scope
  beforeEach(inject(function ($controller, $rootScope) {
    MainCtrl = $controller("PhoneListCtrl as vm", {
      $scope: scope,
    });
  }));

  it("phoneモデルが3つ作成されていること", function () {
    expect(scope.vm.phones.length).toBe(3);
  });
});
```

[$controller](https://docs.angularjs.org/api/ng/service/$controller)で指定する controller の constructor 指定の部分に`as`構文が使えるんですね。知りませんでした。  
$controller でテストする controller を inject したら、scope に設定した model などは`as`で指定した alias(今回だと vm)から参照できるみたい。

ちなみに、constructor で`as`構文を使わないと`expect`するところで`undefined`になります。

```
TypeError: 'undefined' is not an object (evaluating 'scope.phones.length')
```

controllerAs仕様のcontrollerをユニットテストするための小ネタ

AngularJS を利用するメリットの 1 つとして、AngularJS が内包している[$resource](https://docs.angularjs.org/api/ngResource/service/$resource)を利用することで、バックエンドが提供する REST API との対話部分が簡潔に記述できることが挙げられます。

ところが、$resource の表面的な振る舞いを理解しただけでは、意外なところにハマりポイントがあるものです。今日はその辺りを少し紹介します。



[AngularJS Advent Calendar 2014 \- Adventar](https://adventar.org/calendars/350)16 日目の記事です。

- 15 日目[AngularJS - Promise を使おう - Qiita(@teyosh)](http://qiita.com/teyosh/items/d7d3c17f954318c88882)
- 17 日目[AngularJS 1.3 へのアップデート(@kon.yuichi)](https://note.mu/konpyu/n/n1eb6c13c69d6)

## $resource の使い方

> $resourceの細かい内容については[本家ドキュメント](https://docs.angularjs.org/api/ngResource/service/$resource)か[Qiita](http://qiita.com/search?utf8=%E2%9C%93&sort=rel&q=angular+%24resource)でググるといいと思います。

$resourceにURLを渡すだけで以下のような基本的なWebAPIが実行できるようになります。$resource を使う場合、`service`か`factory`の中で利用することがほとんどですね。

```
{
  'get':    {method:'GET'},
  'save':   {method:'POST'},
  'query':  {method:'GET', isArray:true},
  'remove': {method:'DELETE'},
  'delete': {method:'DELETE'}
};
```

また、`PUT`や異なるエンドポイント(URL)など、先ほどの基本的な API をカスタムしたい場合は、`actions($resourceに渡す3つめの引数)`で使うことで簡単に API を追加できるので、使いこなすことが出来るとバックエンドとの WebAPI 連携の部分で非常に重宝します。

**user.service.js**

```js
function User($resource) {
  return $resource('/api/user/:id', {
    id: '@id'
  }, {
    //PUT /api/user/:id
    updata: {
      method: 'PUT'
    },
    //GET /api/user/me
    me: {
      url: '/api/user/me'
    }
  });
});

angular.module('app').factory('User', User);
```

## "$resource の戻り値は実際の値ではない、参照である。"というハマりポイント

> し、しらなかったぜ・・・

結論から言うと、$resource の戻り値は**参照**なので、そこから直接プリミティブ型の値を取り出して他で使う場合には、タイミングによって`undefined`になったりならなかったりするということです。  
(ほとんどの場合、Object をデータバインドして参照経由で実際の値を見ているので、あんまり問題にならないと思います。)

このハマりポイント、あまり遭遇するケースはないかも知れませんし、原因がわからないままなんとなく回避している人もいるかと思います。私の場合、ui-router の`resolve`を使って controller で必要な情報を取得することが多かったため、よく遭遇していました。

**app.route.js**

```js
function Router($stateProvider) {
  $stateProvider.state("main", {
    url: "/",
    templateUrl: "app/main/main.html",
    controller: "MainCtrl",
    controllerAs: "vm",
    // ここでUserリストを事前に取得
    resolve: {
      user: function (User) {
        return User.get({
          id: 1, // ✌(-‿-)✌
        });
      },
    },
  });
}

angular.module("app").config(Router);
```

**main.controller.js**

```js
function MainCtrl(user, socket) {
  var vm = this;
  vm.user = user;

  // WebSocketのチャットルームに参加
  // [TODO]タイミングによってuser.roomIdがundefined
  socket.emit("chatRoom:join", {
    id: user.roomId,
  });
}

angular.module("app").controller("MainCtrl", MainCtrl);
```

こちらの Stack Overflow を参考にしたのですが、改めて[公式ドキュメント](https://docs.angularjs.org/api/ngResource/service/$resource#usage_returns)読むと書いてありましたね。

> It is important to realize that invoking a $resource object method immediately returns an empty reference  
> ($resource を実行するとね、すぐに空の参照を返すから、心して使え。このボケがぁ！・・・超約)

[json - AngularJs using $resource service. Promise is not resolved by GET request - Stack Overflow](http://stackoverflow.com/questions/20008244/angularjs-using-resource-service-promise-is-not-resolved-by-get-request/20008380?stw=2#20008380)

## $resource との正しい(安全な)付き合いかた

より安全なコードの書き方は、$resourceが返すpromiseを、次のように`$promise`から取り出して処理すると安全です。

**main.controller.js**

```js
function MainCtrl(user, socket) {
  var vm = this;

  user.$promise.then(function (user) {
    vm.user = user;
    // WebSocketのチャットルームに参加
    socket.emit("chatroom:join", {
      id: user.roomId,
    });
  });
}

angular.module("app").controller("MainCtrl", MainCtrl);
```

各コントローラで promise を処理するのが面倒な場合は、15 日目[AngularJS - Promise を使おう - Qiita(@teyosh)](http://qiita.com/teyosh/items/d7d3c17f954318c88882)で紹介されているような、promise を処理するための factory を作ってラップするといいと思います。  
(たしか、<a target="_blank" href="https://www.amazon.co.jp/gp/product/4873116678/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4873116678&linkCode=as2&tag=mitsuruog-22&linkId=bdd0c9b0152b6260907ab4e64036c67a">AngularJS アプリケーション開発ガイド</a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=mitsuruog-22&l=am2&o=9&a=4873116678" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />のサンプルもそうなってたはず。)

<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="https://rcm-fe.amazon-adsystem.com/e/cm?ref=tf_til&t=mitsuruog-22&m=amazon&o=9&p=8&l=as1&IS1=1&detail=1&asins=4873116678&linkId=d152ad4c622d40713fb4691ba63bcb90&bc1=000000&lt1=_blank&fc1=333333&lc1=0066c0&bg1=ffffff&f=ifr">
    </iframe>
    
## まとめ

今日は$resource を使うと便利ですが、ちょっとハマるよという話をしました。

AngularJS はフロントエンドの実装を大変楽にしてくれるフレームワークです。しかし同時に、その裏でフレームワークが隠蔽している技術の難しさを軽視することはできないと改めて思い知りました。

今回のようなケースは、Javascript の実装についてある程度の経験がないとあたりがつけにくい問題だったと思います。(ドキュメント読めは置いといて・・・)  
AngularJS に限らず、JS フレームワークを利用する場合は、チームの中に本当の Javascripter(Hacker ともいう)がいるかが、成功の秘訣のような気がします。

AngularJSの$resourceの意外なハマりポイント

最近の AngularJS 開発では[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)をオレオレカスタムしたものを使っています。 fullstack だけあって使いこなすまで慣れがいると思いますので、私が普段使いしていていいなって思う機能を紹介します。  
AngularJS 開発の厳しい旅のお供にどうぞ。

この記事は[YEOMAN Advent Calendar 2014 - Adventar](http://www.adventar.org/calendars/356)9 日目の記事です。

- 8 日目[YEOMAN Advent Calendar 8 日目：generator-ember を紹介します - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/12/08/120810)
- 10 日目[YEOMAN Advent Calendar 10 日目：generator-reveal を紹介します - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/12/10/143324)



## 基本的な使い方

基本的な使い方はこちらを参照してください。そんなに難しくないはず。

[DaftMonk/generator-angular-fullstack | usage](https://github.com/DaftMonk/generator-angular-fullstack#usage)

注意点としては、アプリを generate する際に`mongodbあり`を選択した場合は、mongodb が起動していないと動作しないとこでしょうか・・・

> npm install する際に`grunt-contrib-imagemin`でエラーが発生する場合、もう一度 npm install するか、一度 uninstall して install するといいです。
>
> ```
> npm uninstall grunt-contrib-imagemin --save-dev
> npm install grunt-contrib-imagemin --save-dev
> ```

アプリケーションの雛形を作成したら、機能を追加する際にこちらのサブジェネレータを利用するとソースコードを自動生成してくれます。

[DaftMonk/generator-angular-fullstack | generators](https://github.com/DaftMonk/generator-angular-fullstack#generators)

では、ここから generator-angular-fullstack(以下、fullstack)の便利機能を少し紹介していきます。

## OAuth 認証テンプレート

fullstack には`google+`, `twitter`, `facebook`の OAuth テンプレートが付属しています。これに加えて`user/password`形式の Form も付属しているので、認証が必要なアプリケーションを作成する場合は、非常に助かると思います。  
OAuth のモジュールは[Passport](http://passportjs.org/)を利用しています。

利用方法は、`serve>config>local.env.sample.js`を同じフォルダにコピーして、`local.env.js`にリネームしてからファイルの中身に AppID などを設定すれば利用できます。

例) local.env.js

```
module.exports = {
  DOMAIN:           'http://localhost:9000',
  SESSION_SECRET:   'some-secret-key',

  FACEBOOK_ID:      'app-id',
  FACEBOOK_SECRET:  'secret',

  TWITTER_ID:       'app-id',
  TWITTER_SECRET:   'secret',

  GOOGLE_ID:        'app-id',
  GOOGLE_SECRET:    'secret',

  // Control debug level for modules using visionmedia/debug
  DEBUG: ''
};
```

注意点としては、local.env.js は`.gitignore`に指定されているので、各環境ごとに作成する必要があります。うっかり、作成忘れると認証エラーでハマります。  
それから、`DOMAIN`は OAuth の callbackURL として fullstack 側で利用しているので、これも環境ごとに正しく設定する必要があります。

## livereload & auto restart

今風の高速フロントエンド開発の象徴ともいうべき livereload と auto restart。当然 fullstack にも付属しています。

フロント側を変更した場合は、ブラウザがリロードされ、サーバー側を変更した場合は、Node が restart します。

## Node inspector

> まさか、まだ`console.log()`じゃないですよね！そんなあなたのために。

Node.js のデバックには[node-inspector/node-inspector](https://github.com/node-inspector/node-inspector)を使うのが一般的だと思うのですが、
しばらく触っていないと使い方をすぐ忘れてしまします。幸い fullstack ではサーバーをデバックモードで起動する Grunt タスクとして組み込まれているので忘れにくくなりました。

```
grunt serve:debug
```

コマンドを叩くと、Node inspector が立ち上がってくるのですが、`--debug-brk`指定されているので最初のステップのブレイクポイントで止まっています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/node-Inspector.png)

ブレイクポイントから処理を進めると通常通りサーバーが起動してくるので`http://localhsot:9000`にてアプリの動作を確認しながら、Node 側のデバックもできます。

## mongodb テストデータ自動投入

サーバー起動時に動作環境を選択できます。デフォルトは`Development`になっていると思いますので、起動時に mongodb のテストの洗い替えを行ってくれます。  
テストデータは`server>config>seed.js`に初期設定されていて、最初は`Thing`と`User`のデータがセットされているはずです。ここにテストデータを追加してください。

テストデータ投入の有無は各動作環境ごとの config にて選択できます。`server>config>environment`以下の各環境ごとの設定ファイルが置かれているので、`seedDB`フラグを切り替えてください。

例) development.js

```
module.exports = {
  // MongoDB connection options
  mongo: {
    uri: 'mongodb://localhost/someapp-dev'
  },
  seedDB: true
};

```

## index.html へ必要なフロント側リソースの自動挿入

> 404...はいはい、あれね。

AngularJS でアプリケーションを作成していると、非常にファイル数が大きくなる傾向にあると思います。ファイル追加のたびにわざわざ`index.html`に`<script>`タグなど追加していくのが、非常に億劫になりますね。

fullstack では[klei/grunt-injector](https://github.com/klei/grunt-injector)を利用することで、面倒な`index.html`へのリソース追加を強力にサポートしてくれます。  
`index.html`を確認すると見慣れない``や``のコメントがありますが、この部分に必要な`*.js`や`*.css`を挿入します。bower モジュールも対応しているのがいいですね。

## 本番ビルド

Grunt コマンドで一発本番ビルドできるのも嬉しいですね。

```
grunt build
```

ちなみに次のようなことをしてくれます。

- js, css の結合と minify とリビジョン番号振り
- html の minify
- image の minify
- AngularJS の minify 地雷除去
- AngularJS のテンプレート結合と minify と cache

1 からタスク作ると大変だと思います。

## その他カスタム

これら普通にあるものを利用してもかなり捗るのですが、自分なりにカスタムしている部分を紹介します。  
(これも好みの問題でしょうが・・・)

### サブジェネレータのテンプレート

generator-angular-fullstack が作成するコードのテンプレートを変更したいケースがある場合は、`.yo-rc.json`の中身を変更します。  
`generator-ng-component`の中に`~Templates`というプロパティがあるので、そこにサブジェネレータが参照するテンプレートがあるパスを設定します。

.yo-rc.json

```json
  "generator-ng-component": {

    // 省略

    "directiveSimpleTemplates": "/templates/directiveSimple",
    "directiveComplexTemplates": "/templates/directiveComplex",
    "filterTemplates": "",
    "serviceTemplates": "",
    "factoryTemplates": "",
    "controllerTemplates": "",
    "decoratorTemplates": "",
    "providerTemplates": "",
    "routeTemplates": ""
  }
```

### jsLint, csslint

generator-angular-fullstack では jsLint は付属していますが、csslint は付属していません。 jsLint もチェックタイミングについてもファイル変更時に頻繁にチェックするようにしています。

とくに、css はコンポーネントっぽいフォルダ構成になっているため、スタイルクラス名などにプリフィクスなどつけてサンドボックス化までしてくれるかと期待してましたが、そこまではやってくれませんでした。  
さらにおかしな CSS を書くと minify した時にスタイル崩れが発覚して厄介ですので、`cssLint`は必須ですね。

### socket.io

フロントとサーバー側で socket.io のコンポーネントが付属するのですが、私の作るアプリではいまいちユースケースが合わないので、作り変えてます。  
ツールに使われず、必要に応じてカスタムして使いこなす姿勢が大事だと思います。

## まとめ

私が普段使いしている[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)の便利機能について紹介しました。  
まだ他にも便利機能があると思いますので探してみてください。

本格的は AngularJS 開発を行う場合は、このような開発を下支えするツールが必須だと思います。手に馴染んでくると本当に手放せなくなります。

> 本来であれば、こんなにも難しくなってしまった Web 開発の現状を嘆くべきでしょうが・・・

一度使ったらやめられないMEANスタック開発が捗るgenerator-angular-fullstackの便利機能の紹介

フロントエンドの世界では、日々新しいフレームワークやライブラリが生まれています。
初めてそういった新しいものを習得する場合に、なるべくなら近道したいと思うのが人の気持ちだと思います。  
まず大変なのが、Hello World から実際のプロダクトやプロトタイプで利用する場合で、これは初めてで何もわからない土地を一人で散策するような感覚にも似ています。

今日、紹介するのは私が進化の早いフロントエンドの世界で、より早く未開の土地に慣れるために**スタイルガイド**を有効活用しているという話です。



ちなみにこの記事は[Frontrend Advent Calendar 2014 - Qiita](http://qiita.com/advent-calendar/2014/frontrend)の 6 日目の記事です。

- 5 日目[はじめての CSS 設計 - Qiita(@moschann)](http://qiita.com/moschann/items/c7cbf62056d77cbc1d66)
- 7 日目[CSS のプリプロセスとポストプロセス、そして Rework と PostCSS(@morishitter)](http://morishitter.hatenablog.com/entry/2014/12/07/000205)

## 良いスタイルガイドとは

巷にはスタイルガイド(コーディング規約)と銘打ったものがあふれています。
そのため有効に活用できるスタイルガイドを自身で見極めなければなりません。  
頼りにするスタイルガイドが大雑把で必要なことが書いてなかったり、1000 ページもあってすぐ必要な場所が探せないようでは使えません。

私がスタイルガイドを見たときに良さそうだなと思うのは次のような場合です。

- 目次をみて言語やフレームワークの機能を網羅しているか
- `Bad`と`Recommended`の両方のスタイルが提示されているか
- そのスタイルに至った理由や背景が書かれているか
- スタイルの提示だけではなく、具体的なユースケースが提示されているか

このようなことを頭の片隅に置きながら、自分にあったスタイルガイドを探すといいと思います。

## なぜスタイルガイド？

私がスタイルガイドを読む理由はいくつかあるので紹介しますね。

### 良いコードを書くために悩む時間を短縮

例えば、Javascript でのオブジェクトや配列の定義の仕方については、通常`{}`と`[]`が使われると思いますが、Javascript の言語自体あまり普段やらない人にとってはそれすらわからないと思います。

```js
// bad
var item = new Object();

// good
var item = {};

// bad
var items = new Array();

// good
var items = [];
```

> [mitsuruog/Javacript-style-guide | オブジェクト](http://mitsuruog.github.io/javacript-style-guide/#objects)より

スタイルガイドを読むことで基本的な部分では悩まなくなります。基本的なことで悩まないということは、本当にやるべきところで悩むことに集中するために大切なことです。

様々な書き方存在する中で良いコードを書くために悩む時間を少なくしたいですね。  
(とはいえ、悩むのですが。。。)

### 地雷源を早期に把握

良いスタイルガイドには、先人達がその言語やフレームワークにて発見した地雷源が記載されています。

例えば、AngularJS で controller などを作成する際に、複数の書き方ができるのですが、スタイルガイドを読むことで悩むことなく自分が書くべきコードを見つけることができました。

> 世の中のサンプルは avoid で実装されていることが多いです。それを疑わないままそのまま覚えてしまうことは危険です。

```js
/* avoid */
angular
  .module("app")
  .controller("Dashboard", [
    "$location",
    "$routeParams",
    "common",
    "dataservice",
    function Dashboard($location, $routeParams, common, dataservice) {},
  ]);

/* recommended */
angular.module("app").controller("Dashboard", Dashboard);

Dashboard.$inject = ["$location", "$routeParams", "common", "dataservice"];

function Dashboard($location, $routeParams, common, dataservice) {}
```

> [johnpapa/angularjs-styleguide | Manually Identify Dependencies](https://github.com/johnpapa/angularjs-styleguide#style-y091)より

また、DI の部分を以下のように省略して書いてしまうとソースコードを Minify したときにエラーになるという地雷も発見することができました。

```
/* avoid - not minification-safe*/
angular
    .module('app')
    .controller('Dashboard', Dashboard);

function Dashboard(common, dataservice) {
}

/* recommended - minification-safe*/
angular
    .module('app')
    .controller('Dashboard', Dashboard);

Dashboard.$inject = ['common', 'dataservice'];

function Dashboard(common, dataservice) {
}
```

> [johnpapa/angularjs-styleguide | UnSafe from Minification](https://github.com/johnpapa/angularjs-styleguide#style-y090)より

これらの先人たちの地と涙を汗の結晶である**地雷源情報**を参考にしない手はありませんね。

### コードリーディング時間の短縮

チームで作業する場合に、同じスタイルガイドを参照することで統一感のあるコードを書くことができます。

これは OSS でも同じことで同じスタイルガイドに習うことで他人のコードも読みやすく、また自分のコードも読んでもらいやすくなります。

例えば、Nodejs では API 呼び出しの最後の引数に function を渡すことで、API 呼び出し後に callback を実行させることが慣例となっています。(引数が 1 つの場合はそれが callback になることが多いです。)

express のサーバー作成のコードを例として提示します。

```js
// Setup server
var app = require("express")();
var server = require("http").createServer(app);

// Start server
// [MEMO]3番目のfunctionがcallback
server.listen(port, ip, function () {
  console.log("Express server listening on %d", port);
});
```

> どこかでこんな内容のガイド見たのですが、忘れてしまいました。知っているかたいましたら教えてください。

自分が作成した node 製モジュールの API で、最初の引数を callback にしてしまった場合はどうでしょうか。
他人が読む場合とてもストレスを感じると思います。

**Go に入れば Go に従えで**はないですが、そのコミュニテイ内でのルールは守ったほうがいいですよね。

## スタイルガイドの紹介

私がよく参照するスタイルガイドを紹介します。これからフロントエンド習得しようと思う方は参照してみてください。  
(よく利用しているフレームワークに偏りあるので、全ては網羅していませんが。。。)

### Javascript

airbnb のスタイルガイドを私が翻訳したものです。(本家はこちら[airbnb/javascript](https://github.com/airbnb/javascript))  
有名なスタイルガイドは他にもいくつかあるのですが、内容とボリュームがちょうどいいと思います。

- [mitsuruog/Javacript-style-guide](http://mitsuruog.github.io/javacript-style-guide/)

もうちょっと手が動く様になるとこちらも読むといいです。

- [JavaScript Garden](http://bonsaiden.github.io/JavaScript-Garden/ja/)

### Backbone

スタイルガイドというかパターン集ですね。最近の Backbone は[Marionette.js](http://marionettejs.com/)を併用することが多いので、これはもうあまり出番がないかも。。。

- [rstacruz/Backbone patterns](http://ricostacruz.com/backbone-patterns/)

### AngularJS

AngularJS はこれを読んでおけばいいです。

- [johnpapa/angularjs-styleguide](https://github.com/johnpapa/angularjs-styleguide)

### CSS

基本ですね。

- [idiomatic-css/translations/ja-JP](https://github.com/necolas/idiomatic-css/tree/master/translations/ja-JP)

本格的に勉強したい場合はまずこちらを読むといいです。

- [SMACSS E-book 日本語](http://shop.smacss.com/products/smacss-e-book)

### HTML

結構マークアップで悩む事が多いので、参考になります。

- [hail2u/html-best-practices](https://github.com/hail2u/html-best-practices)

## まとめ

進化の早いフロントエンドの世界ですが、私が進化に追いつくためにスタイルガイドを有効活用しているという話をしました。  
特に最近は特定のフレームワークや言語のスタイルガイドが付属するようなトレンドになってきたような気がしています。  
(ここで言うスタイルガイドは、従来のスタイルガイドとは違うジャンルの新しいタイプのものなのかもしれませんね。)

他の習得方法として、書籍を読む方法もいいと思いますが、スタイルガイドで特性などを把握してから本を読み進んだほうが、途中で挫折しないような気がしています。  
スタイルガイドは面倒な前置きなどないので、忙しいエンジニアは普段使いするには向いていると思いますし。
(書籍の内容は StackOverflow で参照できる内容もおおくありますし。。。)

良いスタイルガイドを知ることは、自分の組織やプロダクトでどのようなスタイルガイドを作成すればいいか、重要なヒントが隠されていると思います。

進化の早いフロントエンドの世界についていくために、スタイルガイドを有効活用しているという話

この記事は[AngularJS Advent Calendar 2014 - Adventar](http://www.adventar.org/calendars/350)の 3 日目の記事です。

- 2 日目[AngularJS BootstrapUI を利用した FilterSelect(@takeyama)](http://qiita.com/takeyama/items/f6e0fbac4d3b4907193e)
- 4 日目[初心者マークの Angular.js - Uemmra3 のフルスタックエンジニア？日記(@Uemmra3)](http://d.hatena.ne.jp/Uemmra3/20141204/1417696122)

AngularJS でそれなりの規模のアプリケーションを書く場合、プロジェクトの構成って結構悩みます。  
いつも悩んでます。。。  
悩みすぎてちょくちょく構成変えるため、たまにアプリケーションが壊れてます。  
そんなとき心もポッキリ壊れそうになります。

そんな私が、最近いいなと思っている AngularJS のプロジェクト構成について紹介します。



## 参考資料(有名どころ)

AngularJS のプロジェクトの構成については、結構以前から議論されています。有名どころではこのあたりでしょうか…  
(正直、これで決まりといったものは無いような気がします。)

- [angular/angular-seed](https://github.com/angular/angular-seed)
- [johnpapa/angularjs-styleguide](https://github.com/johnpapa/angularjs-styleguide#application-structure)
- [Brian Ford/Building Huuuuuge Apps with AngularJS](http://briantford.com/blog/huuuuuge-angular-apps)
- [Angular Best Practice for App Structure (Public)](https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub)

私の場合は[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)を利用することが多いので、基本的には generator-angular-fullstack 構成に
johnpapa/angularjs-styleguide の内容を加味しながらやってます。

## アンチパターン(folders-by-type)

まず、それなりの規模開発をする場合のアンチパターンの紹介。johnpapa/angularjs-styleguide にも載っているのですが、俗に`folders-by-type`と呼ばれるものがアンチパターンとされています。  
AngularJS のモジュールのタイプに合わせてディレクトリを作成して、その中に各機能の javascript ファイルを格納する方式です。

機能が増えるほど、ファイルが分散して大変そうなのが想像できるかと思います。

```
app/
    app.js
    controllers/
        hoge.controller.js
    directives/
        one.directive.js
        one.directive.html
        two.directive.js
        two.directive.html
    services/
        hoge.service.js
        fuga.service.js
    views/
        hoge.html
        some.html
```

## ベストプラクティス(Folders-by-Feature)

アンチパターン(folders-by-type)に対して、良いとされているのが`Folders-by-Feature`と呼ばれる機能単位にフォルダを分ける方法です。機能単位いうよりも**コンポーネント単位**と呼んだ方がしっくりくると思います。

generator-angular-fullstack を使った場合は、次のようなフォルダ構成になります。(`client以下`だけ抜粋)

```
app/
  main/             # 各機能単位のフォルダ
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  bower_components/ # bowerモジュール
```

`main/`の中身は以下のような構成になっていて、URL の Path が`/`の場合に表示する画面のコンポーネント一式が格納されています。

```
main/
  main.js                 # Router
  main.controller.js      # Controller
  main.controller.spec.js # Test spec
  main.html               # Template
  main.css                # Style
```

AngualrJS を使った開発をする場合、Javascript ファイルを細かく分割しながら開発することが多いので、このように機能単位で 1 つのフォルダにまとまっていると見通しがいいです。  
さらにこうすることで、**機能単位で git の branch を作成して開発することが可能**です。

これらのこともあって、それなりの規模感の場合は`Folders-by-Feature`方式を採用する方がいいと思います。

## 自分がカスタムしている部分

基本的に generator-angular-fullstack で作成されたプロジェクト構成をベースに使ってますが、自分なりにカスタムしている部分もあります。そのあたり紹介したいと思います。

### Core モジュールフォルダ

バックエンドのデータアクセスや認証部品など、アプリケーション全体で利用するようなモジュールの置き場所として`app/core`以下を利用しています。

```
app/
  main/             # 各機能単位のフォルダ
  core/             # アプリケーション共有モジュール
    auth/
      auth.service.js
    someApicall/
      someApicall.service.js
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  bower_components/ # bowerモジュール
```

プロジェクトでの再利用観点で`components/`との使い分けなのですが、私の場合は UI が付属するものは`components/`に格納しするように使い分けしています。

### partials テンプレートフォルダ

AngularJS ではテンプレート(html)にディレクティブを書き込んでいくため、テンプレートが大きくなりやすいと感じています。

そこで良く利用するのが`ng-include`です。そのため generator-angular-fullstack:route で作成したフォルダに`partials`フォルダを作成して inclide するテンプレートを格納するようにしています。

```
main/
  main.js                 # Router
  main.controller.js      # Controller
  main.controller.spec.js # Test spec
  main.html               # Template
  main.css                # Style
  partials/               # テンプレート部品
    megaButton.html
    hugeInputArea.html
```

あ、この画面だけで利用する filter なんかも格納しています。

### filters フォルダ

アプリケーション全体で使う filter については置き場所悩みました。現在は直下の`filters`に格納して様子を見ています。

```
app/
  main/             # 各機能単位のフォルダ
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  filters/          # 再利用する想定のfilter
    snsAvater/
      snsAvater.filter.js
      snsAvater.filter.spec.js
  bower_components/ # bowerモジュール
```

### config フォルダ

開発と本番で config を分けたいケースがあるので、`config/environment`以下に実行環境ごとの config を格納しています。

```
app/
  main/             # 各機能単位のフォルダ
  assets/           # 画像ファイルなどのリソース
    images/
  components/       # 再利用する想定のコンポーネント
  config/
    environment/
      development.js  # 開発環境用
      production.js   # 本番環境用
      test.js         # テスト環境用
  bower_components/ # bowerモジュール
```

開発/本番の切り替えは generator-angular-fullstack の Grunt タスクを改造しています。テスト環境の config は`karma.conf.js`にてロードする config を指定しています。

## まとめ

私が普段使っている AngularJS のプロジェクト構成について紹介しました。たぶん半年くらい使ってみてちょくちょく変えると思います。

とはいえ、ぶっちゃけ好みの問題ですけどね・・・

そんな、試行錯誤の成果を[DaftMonk/generator-angular-fullstack](https://github.com/DaftMonk/generator-angular-fullstack)を Fork して[mitsuruog/generator-angular-mitsuruog](https://github.com/mitsuruog/generator-angular-mitsuruog)にまとめています。AngularJS できれいにアプリケーション作りたい人は、Yeoman でオレオレ AngularJS プロジェクトテンプレート作ってみるのもいいと思います。

いま一番気に入っているAngularJSのプロジェクト構成

だいぶ前のことですが、9/22 に行われた[AngularJS リファレンス」出版記念会](http://html5experts.jp/albatrosary/10855/)にて SIer での AngularJS の取り組みについて話させていただきました。

先日、その資料を見て興味を持ってくれた他の SIer にて AngularJS について講演させていただく機会をいただいたこともあり、なぜ AngularJS をいいと感じているのかや、AngularJS に期待することなど、個人的な思いを書いてみたいと思います。(あくまで SIer 目線です。)



詳細は資料を参照してくださいね。

こちらが 9/22 の AngularJS リファレンス出版記念会の資料です。

[今後の Web 開発の未来を考えて angularJS にしました](https://www.slideshare.net/mitsuruogawa33/webangularjs)

他社にて 講演したときの資料です。

[今後の Web 開発の未来を考えて angular js にしました(拡大版)](https:////www.slideshare.net/mitsuruogawa33/webangular-js)

## マルチプラットフォームとしての HTML5

まず、AngularJS を選定する際に外せないのが、「HTML5」の存在です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/why_angular1.png)

ブラウザだけではなくモバイルアプリなど利用範囲が広いため、今後の Web アプリケーションのマルチプラットフォーム実行環境としては主役だなと思います。

## AngularJS の注目ポイント

AngularJS で注目しているポイントとしては次のような部分です。

1.  各モジュールのちょうど良いサイズ感
2.  生産性(4.の要件の範囲内であれば...)
3.  スキルチェンジ(JSP から AngularJS)
4.  Web 開発要件にマッチ

いくつか JS フレームワークを触っていきた経験的に、AngularJS の各モジュール分割(controller や filter など)の考え方は割と Better かなと思います。強いて言えば、規模が大きくなってくると細かな Service がたくさんできて DI が多くなるのが辛いといったとこでしょうか。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/why_angular2.png)

スキルチェンジに関しては、JSP と AngularJS はテンプレート部分にロジックを記述していくため、Javascript で全てテンプレートを生成するものより、理解しやすいと思います。また DI の概念や、各モジュールについての役割についても Java での Web 開発を例に説明できると思います。

## 開発支援ツールとしての Yeoman

私が Yeoman の存在を知ったのは 2013 年の 10 月くらいだったかと思います。

従来の Java での Web 開発と比較して、Yeoman が提供する Grunt タスク(特にフロント側リソースの本番ビルド)はかなりオーバースペックに見えたこともあり、ここ 1 年、少し慎重に評価していました。

AngularJS 開発にあたって Yeoman が必須な訳ではありませんので、Yeoman を使わずに自分の組織にあった Grunt タスクを 0 から作成して利用してもいいと思います。
(Yeoman は必須ではなくても、Grunt タスクは AngularJS 開発では必要だと思います。)

私の場合、当初は Yeoman を利用しない方向で考えていましたが、AngularJS を開発するにあたりいろいろとタスクを追加した結果、Yeoman でのタスクの劣化版を作っていることに気づきました。  
いまでは既存の Yeoman ジェネレーターを自組織に合うようにカスタムして利用しています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/why_angular3.png)

> 本来は、なぜフロント開発がこんなにも複雑になってしまったのかを嘆くべきなのでしょうが。。。

## まとめ

個人的な AngularJS についての思いを書いてみました。  
SIer の中にいると、最近の Web 開発手法の進化と現場での意識のギャップに戸惑うことが非常に多いです。

AngularJS もそろそろ実用レベルのものに達してきたと思いますので、このあたりで少し実戦で使っておかないと、10 年後には Web 開発がまともにできないような組織になるのではと危惧しています。

SIer じゃなければ React.js か vue.js を使いたいです w

なぜAngularJSを薦めるのか ー 個人的な思い

先日、HTML5j エンタープライズ部のメンバーと最近気になっていた Flux アーキテクチャについて味見してみました。
巷の AngularJS のサンプルは ES6 で書かれたもの多いので、実務でも使える ES5 で書きなおしてみました。

- デモはこちら [Angular Flux ES5](http://mitsuruog.github.io/angular-flux-es5/)
- コードはこちら [mitsuruog/angular-flux-es5](https://github.com/mitsuruog/angular-flux-es5)



Flux の概要については[@albatrosary](https://twitter.com/albatrosary)さんのブログを参照してください。

[What’s Flux? - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/10/22/131302)

## 雑感

フレームワークの書き方が一通りわかると、次はもっと効率的に書くにはどうするかとか考え出します。
Backbone の時もそうだったのですが、SPA でフロント側を作った場合、model の変更を複数ある view 側にどう伝えるのがいいか、悩んで手が止まります。
(Backbone の時はグローバルの Mediator を通して model の変更を通知してました。当時の残骸はこちら[mitsuruog/SPA-with-Backbone](https://github.com/mitsuruog/SPA-with-Backbone))

AngularJS の場合は`shared services`を使うか、`$rootScope.$broadcast`を使うことが王道かなと思います。
個人的には`shared services`の方が小さくて好みです。

[AngularJS - Angular JS で複数のコントローラ間でモデル（状態や値）を共有する方法 3 種類 - Qiita](http://qiita.com/sunny4381/items/aeae1e154346b5cf6009)

Flux アーキテクチャを使った場合は、Angular way にならないので、これはこれでありかなと思いました。
ただ、Observer の制御を間違えるとメッセージパッシングが無限ループしだして死にます。(参加メンバーはもれなく無限ループを体験していました w)

## まとめ

Angular の場合は、無理して Flux 使うより`shared services`の方がコードは読みやすくなると思います。
そろそろ SPA のアーキテクチャについても、かなり出尽くした感がしますね。

Tag: angularjs