为什么在控制器中操纵DOM是一件坏事?

它的常见知识是DOM操作不应该在AngularJS Controller中执行,但它很难找到为什么它是一件坏事。 所有的消息来源都说它很难测试,因为控制器应该用于指令之间的通信,但是没有用代码说明为什么这是一件坏事。

根据我的理解,我认为控制器与指令不同,不会与任何特定的HTML相关联,因此所有DOM修改控制器将会执行的操作很可能会失败。 这肯定会使开发和测试复杂化。

在指令的控制器在子指令的链接函数之前执行也会失败,因为控制器可能不知道子指令的实际HTML是什么。 链接在控制器功能之后执行并可能修改HTML结构。

我希望我在这里有意义,如果有人能够澄清为什么从控制器操纵DOM是一件坏事,也许有一些代码示例或链接可以很好地解释它。


使用代码示例证明自己的观点更加困难的原因是,原因不能通过短代码片段(对于堆栈溢出足够短)来表示。 这实际上是一种可维护性的预防措施。 从长远来看,您希望能够独立地更改控制器和视图背后的逻辑,因为否则,耦合的控制器和视图对往往会保持这种方式并限制对方改变其功能而不会破坏其他功能的能力。 只要你决定改变视图的任何内容,你就有机会让你的控制器代码中断,甚至没有触及它。

随着时间的推移,测试变得越来越容易,因为您拥有的测试越多,您希望事物的模块化程度越高并且依赖尽可能少的变量和参数。

同样,推动这一建议的是维护。 上面列出的问题可能并不是那么糟糕的出发点。 但是想象一下,如果你没有从头开始构建一个项目,并且知道控制器和视图之间的耦合背后的所有复杂因素,那么这个应用程序就可以同时使用。 如果你的应用程序有成千上万行代码,那么即使你从头开始构建它,你也不可能知道所有这些错综复杂的东西?

为了更加全面地理解为什么像您提到的设计模式是必要的,您可以参考这个谷歌搜索,只要您愿意,这个谷歌搜索就会带您踏上旅途。 为了全面了解为什么设计模式甚至存在以及为什么很多人最终会一遍又一遍地提出相同的事情,您可以参考设计模式介绍的一个催化剂,克里斯托弗亚历山大。 他向我们表明,模式是他们的所为,因为他们工作得很好,人们重复一切运作良好。


如果你看到如此流行的问题“Thinking in AngularJS”,如果我有jQuery背景吗? 你会得到一些提示。

我认为DOM操作既不需要也不需要做的最大因素之一是Angular在涉及到DOM链接时使用声明式方法,而不是直接DOM操作使用的命令式方法。 一些答案详细说明了声明式和命令式方法之间的区别。

使用jQuery,您可以一步一步地告诉DOM需要发生的事情。 用AngularJS描述你想要的结果,但不知道如何去做。 更多关于这里。 另外,请查看Mark Rajcok的回答。

关于这个主题的更全面的处理也可以在这里声明式和命令式编程有什么区别

通过这种方法,控制器实现得以简化,随着代码库规模的增长和复杂性的增加,我们开始获得真正的价值。


我的观点有点不同,涵盖的不仅仅是测试。 这是设计者控制HTML布局的能力,否则将通过在Angular Controller中编写代码来接管。 考虑下面的代码片段(这只是一个简单的例子)

<div ng-repeat="article in articles">
    <p class="article-body">{{article.text}}</p>
</div>

这个例子只是迭代一个集合并在单独的段落标签中打印文章。 虽然肯定有可能在Angular Controller中循环收集并动态生成带有文本的段落标签。 它将消除设计者修改外观和感觉的能力。 因此,如果有要求显示文章标题,而不是这样做

<div ng-repeat="article in articles">
    <span class="article-title">{{article.title}}</span>
    <p class="article-body">{{article.text}}</p>
</div>

设计师现在必须找到Angular Controller代码来修改DOM操作。 只需比较以上两种方法,并猜测哪一种会提供更大的灵活性。

链接地址: http://www.djcxy.com/p/22879.html

上一篇: why manipulating DOM in controller is a bad thing?

下一篇: Angular2 innerHtml binding remove style attribute