Angular.js: 反馈请求：`angular.component()` - 默认指令控制器名称

c) 程序员倾向于使用isolate:false并直接访问祖先控制器。

@drpicox - 我很想说我们禁止isolate: false用于使用此帮助程序创建的组件。

我同意，考虑到这一点：

• isolate: true当restrict 为'E'时：对我来说它们是真正的组件，其中$ctrl 表示法具有完整含义
• isolate: false当restrict 为'A' 时：对我来说，它们是_decorators_，一种现有组件的增强器，在这种情况下，$ctrl 会发生冲突，因此当前的命名法没问题

但我认为第二种情况最好用指令，_decorators_不常见，通常是低级的，不适合初级。

所以禁止isolate: false可能是个好主意。

换个思路，关于_decorators_，一个函数来获取当前实体的'E'组件的控制器应该是个好主意，专门写泛型的_decorators_来处理任何当前的组件（需要强制提前知道哪个控制器是，你不能使用一种你正在寻找的界面）。

我喜欢$cmp ，但发现$comp更好，因为它更清晰。

我喜欢$cmp ，但发现$comp更好，因为它更清晰。

我喜欢$comp 。 每当我看到$cmp时，我都会想“比较”。

不同的建议：为什么不将组件的名称作为控制器实例名称？
例如：用户配置文件-> scope.userProfile

@tabanliviu这就是目前在master上的做法，但@petebacondarwin在这个问题中提到，在第一篇文章中，为什么一个通用名称更好。

@mgol :+1：我想我在读票时掩盖了这一点。 是否应该将此更改视为更多 ngUpgrade 问题？ 我认为在 angular 1.x 的上下文中，当前的实现是一个很好的解决方案。 也许将其公开为一个设置函数，该函数采用组件名称并输出控制器名称？ 这样，它服务于当前模式和未来的迁移路径。

自行车棚时间。

+1 为 $ctrl。

Ctrl 在 Angular 1 文档和示例中作为“控制器”后缀有很多预先存在的文化。 尝试使用谷歌搜索“angular ctrl”以获得良好的测量效果。

当前从组件名称派生它的选择非常讨厌，因为它们在实际应用程序中确实往往会变得很长。

:+1: 对于$ctrl ，作为默认值的$vm感觉更像是在说明应该如何使用控制器。

+1 $ctrl 。

我们在 ng-forward 团队中对此进行了激烈的辩论，并决定ctrl是一个比vm更轻的术语。

我投票支持$ctrl ，如果这鼓励人们不再调用他们的控制器vm $，我会非常高兴：P

哦，我也想补充一下

这可能与输入控制元素混淆

不。 并不真地。

$ctrl

我认为这对每个人来说都是最容易理解和最直观的。

+1 $ctrl

其他建议：

1. $as - 像控制器一样
2. $at - 像 @ - 在咖啡脚本中它引用 'this' 上下文
3. $class - 虽然是 5 个字符，但它接近 ng2 组件类表示法。
4. $prox - 从概念上讲，Ctrl 实例是服务层的代理
5. $ctx - 上下文的快捷方式
   谢谢。

我投票支持$this是因为在 ng2 中，控制器的this是模板的上下文（我认为component在 ng1 和 ng2 之间充当过渡工具的作用非常好）。

+1 为 $ctrl

我也更喜欢$ctrl属性，因为它代表组件控制器。

+1 为 $ctrl

为 $this +1

我什至会选择this并放弃$ ，如果它不是太难的话。 它也是唯一不缩写为其他东西的选项，我讨厌缩写。 :)

我会选择 $ctrl 或 $cc （组件控制器的缩写）

+1 为 $ctrl

我们可以只称它为$troll ，它有一点$this和一半$controller 。 不，开个玩笑，我可以接受$ctrl 。 :+1:

$ctrl + 1

$vm

优点

• 更少的新概念
• 短的
• 并不代表对象的真正含义（但过渡的开发人员会得到它……这就是重点）

缺点

• 并不代表对象的真正含义（但过渡的开发人员会得到它……这就是重点）

$ctx - 上下文的快捷方式。

比$ctrl $vm匿名，不像$comp或$this那样令人困惑。

我查看了模板引擎（Jade、Handlebars、Mustache.js、Dust.js、Nunjucks、EJS 等），似乎名称context 、 locals或data用于传递给渲染方法的变量名。

此外，对于上下文， $ctx与$ctrl （或$this ）具有不同的认知超载，实际上，您说的是in Angular 2, where the context is the controller 。

@albertosantini - $ctx的一个问题是实际上下文是当前范围，也可以通过this直接访问。

$vc - 代表视图控制器。
我在苹果的文档中找到了参考

tldr;

“...UIViewController 类定义了管理视图、处理事件的方法和属性...”

我强烈投票支持$this ：

<textarea ng-change="$this.handleChange">

_优点：_

• 最大的优势：你不需要在你的控制器中做任何ctrl = this来使两个实体看起来一样。
• 除了$this之外的任何东西都感觉 Angular 甚至引入了“更专有的语言”_，这是对 Angular 的普遍抱怨之一。 您的控制器将像这样被污染：

  controller: function() {
    var ctrl = this;

    ctrl.items = [];
    ctrl.text = '';
    ctrl.handleSubmit = function () {
        ctrl.items.push({text: ctrl.text});
        ctrl.text = '';
    };
  }

而不是更简洁、优雅且与框架无关的

  controller: function() {
    this.items = [];
    this.text = '';
    this.handleSubmit = function () {
       this.items.push({text: this.text});
       this.text = '';
    };

• 后者是一个纯 JavaScript 函数，可以在任何有或没有 Angular 的地方重复使用。 前者会在其他任何地方看起来断章取义。
• 请注意，在后一个片段中，即使是语法荧光笔也是你的朋友，以及在前一个片段中它是如何反击你的。 代码可读性是一个重要问题。
• 此语法类似于其登录页面上显示的 React：

<textarea onChange={this.handleChange}>

• 在 React 中，DOM 上下文和 Controller 实例都被视为完全相同的实体，React 甚至利用了这一点，声称他们的方法更简单。
• Angular 肯定不是 React，但是很多人都在使用或查看两者，所以更多的相似性会让他们感觉更友好，也不会让他们感到困惑。

@dmitriz AngularJS 中$this的一个问题是，在模板中，上下文（即this ）实际上不是控制器。 似乎在 React（和 Angular 2）中它们确实是一回事，因此使用this （或$this ）是有意义的。 在 Angular 1 中，它们并不相同，因此$this实际上可能会引起更多的混乱。

关于 JavaScript 方面，在 ES5 代码中将this别名为其他东西是很常见的，因为调用自由方法时this的绑定问题。 因此，无论如何，控制器仍然经常有类似var that = this的东西，在这种情况下，不妨使用var ctrl = this 。

话虽如此，如果您不想在控制器中执行此操作，则无需这样做。 IMO 在对象内部使用this是完全合理的，但在从外部使用它时会以其他名称引用对象。

@dmitriz ，您不必在控制器和视图中具有相同的别名（我从不这样做）。 另外，我总是在控制器中使用var self = this ，以避免必须.bind(this)进行回调等。
所以，这不应该是一个问题，imo。

关于其他选项：

• $ctx ：我不喜欢这样，因为（正如@petebacondarwin提到的），控制器不是表达式的上下文。
• $this ：我不喜欢这样，因为（在 Angular 表达式中） this是当前作用域的特殊别名，所以有this --> scope和$this --> controller会更加混乱。 （否则我会喜欢的。）
• $vm ：我不喜欢这个（原因已经提到），但如果没有更好的方法满足我们的限制，我可以接受。
• $cmp ：不是非常令人满意（因为不是 100% 准确），但声明性足够。 如果没有更好的方法满足我们的限制条件，可以使用它。
• $comp ：我更喜欢$cmp ，因为它更短（而且我发现compare比$comp更“容易混淆”）。
• $ctrl ：我非常喜欢这个。 它非常简短，具有声明性并且尽可能准确。 我总是用ctrl我的控制器添加后缀，而且我从未见过任何与ConTRoL混淆的情况（但知识渊博的人坚持认为存在混淆 :)）。 如果我们认为混乱不是问题，我肯定会接受这个，但我可以接受其他事情。
• $troll ：需要多考虑一下。 它当然有潜力 :stuck_out_tongue:
• 其他选项（ $as ， $at ， $cc ， $prox ， $vc ）：我认为他们正在引入新概念，并且会更多令人困惑而不是帮助。

我投票支持$ctrl ，因为它_是_指令控制器。 简单的。

反对其他人：

• $vm -- 正如已经指出的那样，这不是必需的使用意图 => 模式/代码阅读的混乱或开发人员的选择更少（被迫实现 vm）
• $cmp -- 嗯，不是组件本身，而是（仅）控制器？ 所以真的是误导？
• $this -- 也已经提到过，它令人困惑。 控制器实例在范围内使它成为“this”是什么？ 从语义上讲，我不认为这可能是..好吧..可理解的？
• $ctx -- 实际上与$this相同。

就像 Pascal 已经说过的：我没有看到与控制元素混淆。 除非 Angular2 以这种方式注入所有 DOM/输入元素（即 $ctrl、$val、$cmbx 等），否则我认为这不是问题。

+1 $ctrl

在与先前评论相同的行中：

• $vm , $as , $at , $cc , $prox , $vc , $ctx ,. ..：向程序员引入新的不必要的概念
• $this ：因为this已经存在，可能会让程序员感到困惑
• $cmp或$comp ：（首先更好）它应该很好，因为它将程序员集中在组件模型中，但它们可能不是直截了当
• $ctrl ：只是在范围内发布的内容，即控制器，因此看起来非常清晰易于理解和使用

我明白了，感谢您的澄清，我不知道this = $scope但是，是的，排除了它。

然后$ctrl听起来像是下一个最佳选择，除了$troll是:)

+1 $ctrl ：最直观、最通用

@petebacondarwin感谢您提供详细信息。

所以 +1 为$ctrl 。

我更喜欢声明性的$ctrl作为默认名称。

为什么不好？

@petebacondarwin @PascalPrecht

为什么 VM 不是一个很好的代表？

（如果您已经在其他问题上讨论过它，请尽可能链接到它）

因为 AFAIK，Angular 中的控制器更接近于视图模型，而不是 MVC 中的经典控制器。 但也许我错过了一些东西。

+1 为 $vm

我同意@QuinntyneBrown的观点——

它更短。

但更重要的是——

@johnpapa的风格指南非常受欢迎，我认识的很多人都将其称为“新开发人员”培训计划的一部分。

如果我们在这里改变它，我们应该考虑它对新开发者的影响（也许向风格指南提交 PR）

这就是为什么我喜欢较短的“$vm”名称（顺便说一句，为什么它必须以$开头？:)

（顺便说一句，为什么它必须以 $ 开头？:)

Angular 定义的名称以$开头，当它们与程序员定义共享名称空间时，它可以避免冲突。 在这种情况下，它是由 Angular 定义的，并且是在范围内定义的，程序员可以有自己的定义。 使用$我们避免了名称冲突，并且 Angular 的行为与程序员的期望一致。

（@johnpapa）这个风格指南的目的是通过展示我使用的约定，更重要的是，我选择它们的原因，为构建 Angular 应用程序提供指导。

样式 Y032在使用 controllerAs 语法时为此使用捕获变量。 选择一致的变量名称，例如 vm，代表 ViewModel。

因此，它是vm 、 ctrl还是troll都没有关系，它必须是一个一致的变量。
另外，正如我之前指出的，想法不是添加新概念： vm代表ViewModel ，如果您没有使用 View Models 或者不熟悉它，您将不会理解vm或ViewModel代表什么，这会令人困惑。

我不喜欢混淆名字。 我认为ctrl令人困惑。 是控制器吗？ 控制（如 html 控制）？ 这不是一个组件吗？

我投票给vm或comp 。 vm常用且易于解释。 comp是新的，但并不难预测。

$ctlr （即ConTroLleR）而不是$ctrl怎么样？

+1 美元补偿

@petebacondarwin哦，有很多阅读障碍者（比如我自己）会用这方面的问题来轰炸我们...... :)

@drpicox感谢您的解释，我看到了您的观点并且它们是有效的。 这是一个艰难的过程，但我至少可以从我的经验中分享这一点，我教开发人员“vm”约定没有问题，并帮助一些公司以这种方式构建他们的大型应用程序，他们很快就完成了，但也许我'在这次经历中，我独自一人。

但我理解你的观点。 同意$

我仍然支持 $vm，但也可以使用 $comp...

Angular UI Bootstrap 团队的@wesleycho似乎强烈反对vm ：
https://github.com/angular/angular.js/issues/10007#issuecomment -166707284

+1 $ctrl

@shairez我完全同意你关于召开大会的观点，我是一名自由建筑师，背后有数十个项目， vm大会帮助很大，但我仍然有一些问题。 事实证明，有些人拒绝使用它。 如果这个约定来自 Angular 本身，那么阻力可能会更低，但我确信如果名称是$ctrl ，他们会按原样接受它，没有任何阻力。 $ctrl是直截了当的。

所以投票进入了，它看起来像这样：

$comp  4
$cmp   2
$ctrl  19
$vm    3
$this  3
$ctx   2
$vc    1

最喜欢的是$ctrl 。 除了受欢迎之外，它还通过了本期顶部发布的标准。 此外，它没有引入任何特别新的概念。 真正提到的东西是 Angular 开发人员已经理解的控制器（组件/指令控制器），就像一些开发人员已经习惯在他们的指令中使用vm一样，开发人员很快就会使用棉花到这个默认值。

太棒了，$ctrl 就是这样！

1.4 及更低版本的问题 - 无法使用$ctrl命名“名称”

我想提出的另一个问题是，在 Angular 1.4 及更低版本中，我们不能真正使用以$符号开头的“名称”。

它给出了以下错误：
Error: [$controller:ctrlfmt] Badly formed controller string

有些公司无法升级到最新版本，可能需要几个月的时间。

他们仍然想跟上惯例，所以他们的升级过程在未来会更简单。

对他们来说，从vm切换到$ctrl是不可能的。

你怎么看？ 有什么建议？

也许分阶段迁移：
首先将vm转换为ctrl
当 1.5 发布时，“升级” ctrl到$ctrl

另一种可能的方法——虽然很冗长——是在运行时生成 controllerAs 别名，检查angular.version 。 就像是：

 angular
        .module('github')
        .directive('issueThread', issueThread);

    /* <strong i="14">@ngInject</strong> */
    function issueThread () {
        // this can be required as a module if using some module loader
        // or - another way is using global on angular namespace (i know it a bad practice - hwoever just to indicate reuse of this check 
        let prefix = angular.version.minor === 5 ? '$' : '';
        let controllerAs = prefix + 'ctrl';
        // with template strings
        var controllerAs = `${prefix}ctrl`;

        var directive = {
            controller: controller,
            restrict: 'E'
        };
        return directive;

        function controller() {
        }
    }

@orizens模板呢？

@shairez嗯，这是有道理的，$ 符号仅用于角度内部......可能在下一个未成年人中具有某种向前兼容性很好。

@drpicox你说得对:)。
同样，我能想到的一种解决方案（hacky one ...）是，在运行时/构建的模板中用 $ctrl “替换” ctrl。 如果项目是用 es6 和模块构建的，那可以很容易地实现。 否则，这是 gulp/grunt/npm 在构建时的任务。

为什么不直接使用controllerAs ？
这不是一个理想的解决方案（实际上我们可能需要修改从控制器字符串（如果有）中提取标识符的 RegExp，但是使用controllerAs是向后和向前兼容的 :)

（如果有人想尝试更新提取 RegExp 的标识符，顺便说一句，它就在那里。）

@gkalpak这是一个很好的观点，继续推广使用controllerAs属性是好的，因为我相信越来越多的人也将过渡到使用 1.4 及更低版本中的组件。

但是，我认为如果我们开始教人们$ctrl并且在某些情况下有效而在某些情况下无效，那可能会令人困惑。

因此，前向兼容性（不确定如何）是个好主意！

@shairez你（你能）创建一个新问题来跟踪这个吗？

我创建了 #13736 ，它允许在标识符中使用 $ $ ，当使用<ctrl> as <identifier>时。
controller: '... as ...' vs controllerAs: '...'之间允许的标识符仍然不同。

也就是说，我不确定推广controller: '... as $ctrl'是否是跟上惯例的好方法。 升级controller: '... as $ctrl'比升级 $#$ controller: '...', controllerAs: '$ctrl'困难得多。

谢谢@gkalpak - 我同意我们应该鼓励使用controllerAs属性而不是控制器作为语法。

一件事是：组件的文档说：“组件定义非常简单，并且不需要定义通用指令背后的太多复杂性”。
另一个：指令中的控制器仅在您构建相互交谈的复杂指令时才是必需的。 否则，链接功能就绰绰有余了（例如，“当您想将 API 公开给其他指令时使用控制器。否则使用链接”在开发人员指南指令中，并且根据我的经验，指令使用链接而不是控制器使用数百次来实现相同的功能在 ng-repeat 中要快得多。
所以...
我在组件（“简单”指令）中找不到“简单”（链接功能）的方式，只有重型（控制器）。
我错过了什么吗？
感谢您的解释。

@frfancha - 性能改进是由于不必使用$injector来实例化控制器，对吧？ 也许您可以提供一些性能测量？

组件助手的想法是使编写组件类型（隔离，元素）指令更简单（在 LOC 意义上）； 并且更容易编写更符合 Angular 2 中的工作方式的代码。

如果特定应用程序中存在性能问题，那么将组件指令转换为使用更通用的directive帮助程序将相当简单。

我认为我们需要查看其他 API 文档和开发人员指南，以确保它们与新的component()帮助程序一致。

@petebacondarwin一开始我们用控制器编写了所有指令，只是因为它在我们遵循的第一个教程中是这样显示的。
只有在我们发现用 1000 个指令“打开”某个页面需要大约 15 秒（ng-repeat x 200 中的“行”为 5）之后，我们才阅读了有关指令的更多信息，并理解如果你不这样做，控制器将毫无用处“在指令之间说话”（通过要求另一个指令的控制器）。 在使用链接功能而不是控制器“重写”所有内容之后（重写是一个大词，因为它只是复制/粘贴链接而不是控制器中的代码），显示页面的时间是 8 秒。
请注意，这些是 Firefox 的措施，当时我们没有使用 Chrome。 现在我们使用它，我估计 Chrome 中的时间是 Firefox 的三分之一（内存使用量是 Firefox 的三分之一（并且没有内存泄漏，这很好，在 Firefox 中我们的应用程序被称为“下午很慢）”）。
我们通常对 angular 非常满意（我们已将所有数据输入应用程序从 Smalltalk windows 应用程序转换为 WEB API + angular（以防您感兴趣？？我有时在伦敦）。
但我对控制器选择支持“简单方式”执行指令感到惊讶

谢谢@gkalpak ！

@petebacondarwin一个单独的问题不再相关，对吗？ （因为公关）

我同意（正如我所写），我们应该教育人们使用 controllerAs 属性，但只是提到它是因为我预测人们会遇到它。