Angular 风格指南 - 使用 Coffeescript？答案

【问题标题】：Angular style guide - with Coffeescript?Angular 风格指南 - 使用 Coffeescript？
【发布时间】：2014-06-08 15:32:30
【问题描述】：

一位同事在这里找到了一个指南，显然来自谷歌：

https://google-styleguide.googlecode.com/svn/trunk/angularjs-google-style.html

阅读本文后，基于过去 6 个月的 Angular 使用情况，我有一些担忧（我在 Rails 中使用 Angular + Coffee，偶尔会出现 Haml 页面）：

文档似乎建议使用类。

我有一个 PITA 处理依赖于 JS 'this' 设置为任何理智的代码（您可以利用它来调用类方法）。这在回调中尤其痛苦。

我的解决方法是让我的所有方法都绑定到 $scope，并确保所有控制器代码都驻留在 1 个词法范围内，例如：

MyController = ($scope) ->
  $scope.my_callback= ->
    # do something useful, $scope is set to 'the right thing', and don't care about 'this'.

与为控制器创建类的明显建议相反

class MyController
  constructor: (@$scope) ->

  callback: ->
    # @ is in the hands of the caller...

咖啡->JS产生：

var MyController;    
MyController = (function() {
  function MyController($scope) {
    this.$scope = $scope;
  }    
  MyController.prototype.callback = function() {};    
  return MyController;    
})();

请注意，$scope 不在“回调”的词法上下文中，其中： a) 表示您没有挂钩可以挂帽子，并且 b）coffeescript 代码有点混乱......如果该方法不是类方法，则范围将在上下文中:(

提升全局名称。

文档似乎建议使用谷歌关闭库 goog.require/provide 组合。虽然这些是很好的包装器，但它们确实有效地生成了 JS 全局变量（带有“名称间距”）。另一种方法是将所有内容包装在一个函数中（在coffeescript领域，这只是涉及将事物放在一个单独的文件中），并且仅将相关项目“发布”到角度作为指令、服务、控制器或其他内容。这样可以避免将任何全局变量放入 JS 命名空间。

所以...说了这么多：

a) 我可以看到控制器 == 类在你有控制器类层次结构的情况下很有帮助，所以你可以使用子类化。但你真的会这样做吗？您不会将任何常见逻辑分解到库或服务中。有 'this' ""float"" 和没有 '$scope' 的痛苦值得吗？

b) 是否有任何理由将控制器/指令等代码推送到全局 JS 命名空间中？

（p.s 不打算在这里发动一场宗教战争，但我可以忍受；）

【问题讨论】：

标签： ruby-on-rails angularjs coffeescript

【解决方案1】：

将 CoffeeScript 的类用于 Angular 控制器和服务是一个好主意，因为它的代码干净且可读性强。继承是可能的，但我从未测试过。如果你以 Angular 方式初始化控制器和服务，你应该不会遇到全局变量的问题。

this 的问题通常可以使用 CoffeeScript 中的fat arrow => 来解决。

我的控制器如下所示（使用 controller as 时）：

angular.module 'myapp.controller', []
.controller 'MyController', [ '$scope',
    class
        constructor: (@$scope) ->
            @attribute = null
            @$scope.$on 'anEvent', (event, data) => @attribute = data

        getValue: ->
            return @attribute
]

【讨论】：

【解决方案2】：

mm.. 我与控制器中的 CoffeeScript 类斗争了一段时间，但同时尝试学习 Angular 指令/作用域/等是灾难的根源。我真的没有明确需要使用它们所以我放弃了。 Desty 的配方看起来不错，但我认为我连接的 grunt run 注释器无法处理这种格式。

不过，它们确实非常巧妙地进入了服务领域..

angular.module('app')

.factory 'AccountsService', (UserService, AccountsResource, UtilService, $log) ->
  new class
    constructor: ->
      @account = null
      @accounts = []

    save: (account) ->
      res = new AccountsResource(account)
      res.$save()

【讨论】：