javascript - 从不在 DOM 中存储中间程序状态？

Question

我设法遇到了this funny bug有一天，对 DOM 的修改太快导致整个 Internet Explorer 崩溃。所以我在想，如果我以后要更改它们，为什么还要设置这些值呢？ (修改是非常不可预测的，因此完全避免这种情况是不可能的)

一些背景，我的网站更像是一个游戏/应用程序，有很多自定义元素等。性能是关键，移动和修改对象应该快速、流畅且无闪烁。在一次迭代中，大量对象的状态可以被修改。

我的应用程序中的对象现在遵循与此模式类似的内容。 domElement 是 DOM 中使用的实际元素，使用 document.createElement 或 getElementById 创建。

function SetWidth(w) {
  this.width = w;
  this.domElement.style.width = w + "px";
}

显然，一个对象有更多的样式不仅仅是宽度，只是为了简化事情。现在这工作得很好，但是如果我出于某种原因在一个“程序循环”内将一个对象的宽度设置两次怎么办？这意味着 DOM 将被修改两次，但只应显示第二个状态。在大多数新浏览器中，这没有什么区别，因为直到所有用户 javascript 完成后才会呈现页面。但在某些浏览器中，您可以随时获得不可预测的更新。即使没有明显的变化，它会影响性能吗？

另一个问题是，某些元素依赖于附加到 DOM，然后才能设置/获取它们的某些属性，使用下面的模式可以更轻松地避免这种情况。

我想做的是回到老式的渲染循环模式。所以上面的对象看起来像这样:

function SetWidth(w) {
  this.width = w;
  this.stateChanged = true;
}
function Render() {
  if(this.stateChanged)
      this.domElement.style.width = this.width + "px";
}

一旦“程序循环”完成，您将循环遍历每个对象，仅“渲染”它们(或使用一些更复杂的结构来跟踪所有修改的对象)。

对我来说，这似乎违背了拥有 DOM 的全部目的，因为你基本上是在重新发明已经存在的东西，但有时感觉它不能正常工作，所以你必须推出自己的版本。

有人用过类似的东西吗，值得吗？优缺点都有什么？我还需要考虑什么？添加和删​​除对象以及管理 z-index 也应该考虑在内。

Answer 1

需要注意的事情之一是，如果您请求依赖于布局的属性值，浏览器将重新计算布局以获取该值，这可能会花费大量时间。所以“this.style.width = '80px'”会很快，但是“this.style.width = '80px'; var wid = this.clientWidth;”会需要很长很长的时间。当然，如果你使用上面的setWidth/render模式，你将无法获取到的值clientWidth 直到渲染阶段之后。

setWidth/render 模式对于您的用例来说是一个合理的模式，但我会创建一个子对象来保存待处理的布局值，而不是将它们直接存储在“this”对象上。如果您在渲染步骤结束时清空/重新创建子对象，则无需存储单独的 stateChanged 变量，子对象中属性的存在可以达到此目的。