Javascript 创建Dojo dijit的最佳实践是什么？ 创建Dojo dijit的最佳实践是什么？ 纯声明性方法（D） 纯程序方法（P） 两者的结合（D&P） 标准 易于维护 发展最快 最直观 最佳性能 大多数功能和灵活性 上下文

我已经和Dojo一起工作了不到一个月，最近我开始和dijit库一起工作。dijit的一个广为宣传的方面是，它们可以通过编程或声明的方式声明。我总是喜欢在了解最佳实践的情况下使用一套新的工具，并大致了解哪种方法对特定应用程序具有哪些优势/好处

下面的信息来自两种风格的一些个人经验，以及我能够找到的参考资料，这些资料并不多。是我在正式的Dojo文档中找到的关于这个主题的唯一一个，它提供了一些外部视角，其中包含了每个场景的代码如何寻找简单场景的基本演示。这两个链接都是针对旧版本的dojo，在AMD在1.7版中引入之前

纲领性

将Dojo与HTML分离，从而保持HTML的语义纯度

将事件处理程序和小部件放在同一位置，提高可读性

似乎可以更轻松地将值动态分配给属性（例如，使用函数创建唯一ID）

声明的

快速开发--直观、隐含的嵌套，小部件定义与普通HTML元素类似

通过使用data jojo-*属性有效的HTML5

不保留HTML的语义纯度

事件处理程序来自外部脚本，造成了一些复杂性并降低了可读性

初始parseOnLoad会减慢前端小部件的设置

回复说明：请在回复中说明每个标准。请随意提出您认为重要的任何其他标准。我决不是评估最佳实践的专家

更新：

---

在浏览了这方面的更多信息后，我发现，这提供了一些有用的上下文，说明了这些风格差异的含义。

我认为没有最佳实践。就我个人而言，我喜欢同时使用编程代码和声明性代码

我认为将表示层与业务逻辑层分离（有点像业务逻辑层）更有意义。我的意思是，

dijit/form/TextBox

和标准的

HTML元素有什么区别？它们都是表示层的一部分，它们都有相同的用途。唯一的区别是一个是自定义元素，而另一个不是

但另一方面，我把事件处理和验证看作业务逻辑，所以我会把它们放入JavaScript中。您还可以将您的

dojo/store

对象声明为声明性的，这也是我不喜欢的，因为它与我的表示层无关

现在，回到你的观点：

最容易维护：如果我必须更改dijit小部件，那么我可能会查看HTML（关注点分离；表示业务逻辑）。它也更容易找到。例如，如果您知道dijit小部件位于标题的正下方和按钮的正上方，那么您就完全知道在HTML代码中查找的位置。如果我们以编程方式创建它，它可能位于代码中的任何位置

使用开发最快：维护和开发有点相同，但声明性标记的另一个优点是，您编写的标记实际上充当占位符，而您必须以编程方式将每个属性指定给一个值

最直观的：我在第一部分中也提到了这一点（最容易维护）。我还认为，它们还使用了一些标准的HTML属性，比如

标题

，

值

，

占位符

。我不认为这会污染HTML标记，但也会增加可读性

最佳性能：这不是最快的方法，我很清楚。但差距很小，并不是说差距很大。您还可以通过禁用

parseOnLoad

并手动解析需要解析的节点来调整它。另一件好事是最终用户“看到”了一些东西。例如，如果编写以下代码：

<select data-dojo-type="dijit/form/ComboBox"></select>
<input type="text" placeholder="Text..." />

最终用户在加载页面时实际上看到了一些东西（这相当于真实结果的代表），即使页面没有被解析。当您以编程方式创建所有内容时，用户只会看到一个白色页面

大多数功能和灵活性：因为我认为将声明式开发和编程式开发相结合，我可以享受两者的好处。您在以声明方式做任何事情时都会遇到一些障碍（如果您将所有内容都放在HTML中，那么事件处理看起来确实很混乱），但我会用JavaScript代码编写这些内容

另一方面，当你以编程的方式创建一个小部件时，它看起来真的很混乱（这是一个观点），所以我可以在HTML中定义它们，这样会容易得多

---

所以最后我想把两者结合起来写。事件处理程序确实来自外部脚本，但是如果您编写正确的MVC应用程序，它们总是会的（因为它是控制器的一部分，而标记本身是视图的一部分）

我不是说你必须把所有的事件处理程序放在一个文件中，不，多亏了AMD加载器，你可以轻松地添加其他脚本。如果您将某个小部件（或一组小部件）的所有交互分组到文件中，并正确命名这些文件，则很容易找到内容

文件越多，就越小