在SPA中制作干净的id空间有哪些常见的解决方案？

Question

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

我的浅见猜测：

• 为所有名字预先安排id（有点荒谬但......）

• 具有架构的结构名称，例如app/collection/model专用app-collection-model

这样的名称

• 一般拒绝使用id或仅用于大型模块吗？

Answer 1

除非绝对必要，否则请尽量避免使用ID。从CSS或JS引用HTML片段时，坚持使用类而不是ID。你的CSS和JS不应该关心（关注点的分离）关于DOM的确切结构或者有多少＆＃39; foo＆＃39;元素在页面上...他们只是想要在任何＆foo foo＆f;元素是哪些类非常适合。

您完全可以避免使用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。

Answer 2

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

团队应该按照设定的时间间隔聚在一起讨论跨领域的问题（例如，ID的命名策略）。例如，如果使用Scrum敏捷开发方法，团队将定期在Scrum of Scrums＆＃34;开会讨论这个问题。

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

Answer 3

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

如今，有许多方法可以创建不需要ID的可重用HTML组件。

我认为错误：

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

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

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

我的观点是：HTML代码应该只在大项目中编写一次且只编写一次。显然，它曾经写过的事实并不意味着它只能在一个地方呈现，它可以在应用程序的任何地方。

我的建议：

数据绑定救援！

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

Answer 4

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

让我详细介绍一下。

• 我们将Backbone.Marionette与Handlebars模板一起使用。对于每个模板，我们都有一个与每个模板相关联的自定义View类（我们将Backbone.Marionette扩展为具有更多功能）。此View类具有ID和UI元素。 UI元素在模板中编译，因此除非我们在视图类本身中更改UI元素名称，否则我们永远不必更改HTML。因此，我们可以改变我们想要的UI元素的Id，并且不会影响任何事情（差不多）。

• 由于我们对每个窗口小部件使用视图，因此您可以确定它们的标识符或名称，或者您想要调用它，是唯一的。我们在UI元素中使用它作为我们Id的基础。这允许我们重用Widget。

来自Underscore库的

• _.uniqueId()也用于CollectionViews。

希望我帮助，欢呼！

Answer 5

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

良好的解决方案 - 使用bem（http://bem.info/）等工具

Answer 6

为每个开发人员（或模块）或唯一的id前缀。

例如，如果开发人员X正在开发模块Y，那么他的前缀应该是x_，y_或xy_之一。 假设选择了x_，他创建的ID看起来就像x_foo，x_bar，x_thing等。

优点：

1. 避免碰撞ID（显然）。

2. 在整合模块时，ID清楚地表明它们所属的位置 这提供了更好的可读性，这是原始的!!

3. 写x_something令人恼火，以避免过度使用ID 与此同时，没有人会使用它们并不那么令人恼火。

缺点：

1. 这至少会让一些开发者感到不快。 （有些人比其他人灵活性差。）
   可能的补救措施是要求他们将ID更改为x_表格，
   只是在发展结束时，就在整合之前 在此之前，他们可能会使用无前缀的ID名称。

2. 某些模块依赖于其他模块。在整合之前，
   必须共享和正确使用适当的ID名称 虽然这可能需要一些额外的时间，但它（希望）值得。

Answer 7

我更希望看到id仅用于指定模块，窗口小部件，主要部分等。这将导致较少的id，并且大多数命名都由业务逻辑创建。你最终还要构建你的类和标签具有某种本地化的层次结构，例如：#specialWidget h3 {} #specialWidget p {}，您只需选择像$('#specialWidget .some-btn').click()这样的处理程序，而不再喜欢$('#someBtn').click()，因为它只是凌乱而且过于具体。

过去，测试和持续集成是捕捉这样的事情的最佳选择。