在 SPA 中创建干净的 id 空间的常见解决方案是什么？答案

【问题标题】：What are the common solutions for making clean id space in a SPA?在 SPA 中创建干净的 id 空间的常见解决方案是什么？
【发布时间】：2014-09-01 13:35:42
【问题描述】：

情况：多个开发人员在 SPA 的不同部分/模块上远程工作。因此，他们可能会意外地引入具有相同 id 的 HTML 元素。在最终组装之前避免这种情况的常见方法是什么（如果可能，不拒绝 id-usage）？

我的浅薄猜测：

为所有名字预先安排id（有点可笑但是...）
具有架构的结构名称，例如为app/collection/model 指定一个名称，例如app-collection-model
一般拒绝使用ids 还是只用于大型模块？

【问题讨论】：

SPA - 单页应用程序
我想团队之间的对话是更好的方式
不要将 ID 用于任何事情。
目前我正在做一个巨大的 SPA，我们决定使用包名 + “普通”名作为 id。
最正确的答案是测试和continuous integration 和stridercd.com 一样，其余的归结为偏好，并鼓励减少使用id。当然名称很重要，但约定只是很好的组织方式，无论如何都不是万无一失的。

标签： javascript single-page-application naming uniqueidentifier

【解决方案1】：

如果您一次又一次地使用不同的 ID 编写相同的 HTML 代码，那么您就做错了。

现在，有很多方法可以创建不需要 ID 的可重用 HTML 组件。

我认为是错误的：

对于大型项目（涉及多个团队或大量视图），我不认为一次又一次地编写原始 HTML 是一个好主意。

这种方法意味着：代码重复和将来重构的痛苦（考虑在 2 年内重新设计应用程序）。这就是为什么有如此多的 UI 框架可以帮助创建可重用的组件，其中 HTML 只需编写一次并在任何地方使用。最后，您的应用程序将需要一些组件：表格、弹出窗口、表单、子菜单、选项卡..

目标是创建一个包含开发人员无需实际编写任何 HTML 代码即可创建视图的组件的框架。

我的观点是：HTML 代码应该在大型项目中编写一次且仅一次。显然，它只写一次并不意味着它只能在一个地方渲染，它可以在应用程序的任何地方。

我的建议：

数据绑定助你一臂之力！

如果无法进行大的改变，约定是可行的方法。您提出的建议可能有意义，但要小心，每次更改结构时，您的所有 ID 都会出错！

【讨论】：

我不能完全同意你的看法。 If you are writing the same HTML code again and again with different IDs you are doing something wrong. 这并不总是正确的。如果您有多个具有相同字段的屏幕，则您可能具有相同的 id（屏幕 1：关系，屏幕 2：订单..两者都将有一个字段 name 并且可能具有相同的 id）。
@GuyT 我更新了我的答案以澄清我的想法。对不起，如果我没有解释自己！
现在我同意你的看法:)。在当前项目中，我们甚至不使用 HTML（仅 JS），而是让 DOJO 做标记..
:) 没错！就是这样，可重用的组件将这样的 UI 问题集中到一个地方。
另一个事实是更容易卖给客户。您可以使用他们可以毫无问题地切换到另一个框架的论点；）

【解决方案2】：

尽量避免使用 ID，除非绝对必要。从 CSS 或 JS 引用 HTML sn-ps 时，坚持使用类而不是 ID。您的 CSS 和 JS 不应该真正关心（关注点分离）DOM 的确切结构或页面上有多少“foo”元素......他们只是想对任何“foo”元素进行样式设置或操作。哪些课程非常适合。

您不能完全避免 ID...例如，标记您的 HTML 以支持可访问性将需要使用 ID...但是这些 ID 和对它们的引用将被限制在同一个 HTML 文件中（或SPA 模板），所以如果您觉得它们中的任何一个都可能发生冲突，请继续让它们变得冗长/冗长以避免冲突。

当然，这并不能完全解决您的问题。通过专注于类，您避免了生成无效 HTML 和所有事情都崩溃的可能性，但您仍然存在协作问题，即确保人们不会因为使用相同的类名而意外地搞砸彼此的工作。在许多情况下，您实际上希望跨页面使用相同的类。但是，如果您想确保没有冲突（例如，在整个站点中使用通用按钮或排版样式），您可以将每个 HTML 模板包装在 <div class='name-of-this-template'>...</div> 之类的东西中，然后在您的 CSS/JS 选择器中，范围仅在该模板中匹配的选择器：.name-of-this-template .a-class-used-within-the-template。

【讨论】：

+1 用于注意与类名冲突可能发生的问题。 FWIW，我已经通过限定容器（例如，父包装器上的类，如您所建议的那样）或合格的 ID，如 document-editor-save-button（这是额外的输入，但消除了大部分歧义）来处理这个问题。如果需要，我还将即时生成一个 ID 前缀，并将其添加到元素/对元素的引用中。这消除了所有的歧义。

【解决方案3】：

当一个项目由多个团队并行开发时，项目成功的关键因素是团队之间的沟通。

团队应按设定的时间间隔聚在一起讨论跨领域问题（例如，id 的命名策略）。例如，如果使用 Scrum 敏捷开发方法，团队将定期在“Scrum of Scrums”会议中开会讨论此类问题。

通过对话，团队将能够就最适合当时正在开发的组件的命名约定（并记录约定约定以供将来参考）达成一致当时（当我说最好的时候，我的意思是最简单和最容易阅读，同时避免任何命名冲突）。因此，您在并行执行工作时“预先安排”id 的建议并不像您想象的那么荒谬！

【讨论】：

我认为项目范围的命名模式不是 Scrum 会议的合适主题。如果您要完全通过命名模式来解决问题，那很好，但是这些约定需要成为文档化的工件（甚至可能与代码一起签入），因为如果有人在 5 年后搞砸了代码由不同的人维护，重复的 ID 可能会导致难以捕捉的错误。
@RobertLevy “Scrum of Scrum”会议的目的是协调并行团队之间的开发。如果团队在同一个领域工作（即创建 UI 组件），那么关于 ID 的对话是相关的。这些会议的结果将是发展和记录（是的，Scrum 过程确实创建了文档）使用的命名约定。我完全同意标准文档很重要。我的回答是强调我相信标准应该随着时间的推移而发展/发展。

【解决方案4】：

在我的一个项目中，我们遇到了这个确切的问题。我们的快速解决方案和我们下一个代码维护/重构周期的一部分是使用可识别的 html 元素继承带有模板的 JavaScript 容器的属性。

让我说得更详细。

我们使用Backbone.Marionette 和Handlebars 模板。对于每个模板，我们都有一个与每个模板关联的自定义 View 类（我们扩展了 Backbone.Marionette 并具有更多功能）。这个 View 类有一个 ID 和 UI 元素。 UI 元素在模板中编译，因此我们无需更改 HTML，除非我们在视图类本身中更改 UI 元素名称。因此，我们可以随心所欲地更改 UI 元素的 Id，并且不会影响任何东西（几乎）。
由于我们为每个小部件使用视图，因此您可以确定它们的标识符或名称，或者您想怎么称呼它，是唯一的。我们将其用作 UI 元素中 Id 的基础。这允许我们重用 Widget。
Underscore 库中的_.uniqueId() 也经常用于 CollectionViews。

希望我能帮上忙，干杯！

【讨论】：

【解决方案5】：

如果您的代码（问题）非常大，并且您无法重构它，您可以尝试在每次提交之前验证您的 css/html 以查找重复 ID。但对于非常糟糕的情况，这是可能的答案。

很好的解决方案 - 使用像 bem (http://bem.info/) 这样的工具

【讨论】：

有没有比其他乐器更好的文章？
我不使用 bem，但我使用了他们的一些想法：我只使用没有 ID 和困难选择器的长名称类。它为我提供了良好的浏览器性能、代码可读性和树结构（使用 SCSS 3.3 - jsbin.com/vohekupa/2/edit）。 bem、oocss 等都是如此。完整的 bem 说“将每个小部件放在不同的文件夹中”，这保证了文件系统级别的不同名称。 BEM 是 Yandex（俄罗斯 Google）的项目，旨在让数千名开发人员一起工作并为许多问题提供答案。它有一个很好的社区和各种工具，但它是怪物。欲了解更多信息：vimeo.com/38346573

【解决方案6】：

给每个开发者（或模块）或唯一的 id-prefix。

例如，如果开发者 X 正在开发模块 Y，他的前缀应该是 x_、y_ 或 xy_ 之一。
假设x_被选中，他创建的ID看起来像x_foo、x_bar、x_thing等。

优点：

避免 ID 冲突（显然）。
在集成模块时，ID 清楚地表明了它们所属的位置。
这提供了更好的可读性，而且是原始的！！
写x_something 很烦人，可以避免过度使用 ID。
同时，也不会让人讨厌到没人会用。

缺点：

这至少会让一些开发者不高兴。（有些不如其他灵活。）
一种可能的补救措施是要求他们将 ID 更改为 x_ 表单，
仅在开发结束时，在集成之前。
在此之前，他们可能会使用无前缀的 ID 名称。
一些模块依赖于其他模块。在整合之前，
必须共享并正确使用适当的 ID 名称。
虽然这可能需要一些额外的时间，但（希望）是值得的。

【讨论】：

在开发结束时更改某些内容（在投入生产之前？）对我来说听起来不是一个好主意。你会很容易忽略一些事情。对于集成测试，命名空间 id 已经到位。
我同意。 “在集成期间”，我的意思是“就在集成之前”。我会修复答案。谢谢。

【解决方案7】：

我希望看到仅用于指定模块、小部件、主要部分等的 id。这通常会导致更少的 id 和您的大部分命名由您的业务逻辑创建。您最终还会使用一种本地化层次结构来构建您的类和标签，例如：#specialWidget h3 {} #specialWidget p {}，您只需选择您的处理程序，例如 - $('#specialWidget .some-btn').click()，而永远不会喜欢 $('#someBtn').click()，因为它变得混乱且过于具体。

除此之外，测试和持续集成是捕捉此类问题的最佳选择。

【讨论】：

为什么要使用 ID 而不是类？如果你想在页面上有 2 个specialWidgets 会发生什么？此外，在某些重要的地方，您必须使用各个元素的 ID，例如在实现可访问性时，甚至只是在 label 元素上指定 for 属性时。
我并不是要暗示没有必要通过 id 指定的情况。总体而言，人们倾向于过度使用它们，减少数量和保持惯例的简单方法是将它们向上移动。您肯定会为任何倍数使用一个类，并且有些库会强制您使用 id。对于这些情况，您还需要一个约定。