解开心中关于DOM操作的几个结

一、如何修改页面内容？

考察候选人对 DOM 基础知识的掌握程度时，笔者常抛出这样的问题：页面上有个空的无序列表节点，用 ul标签表示，要往列表中插入3个li，每个列表项的文本内容是列表项的插入顺序，取值 1, 2, 3，怎么用原生的 JS 实现这个需求？同时约定，为方便获取节点引用，可以根据需要为ul节点加上 id 或者 class 属性。

超过 80% 的候选人能完成需求，先为 ul 加上选择符：

 <ul id="list"></ul>

然后给出节点创建代码：

也有候选人给出下面的代码：

这个都写不出来的同学要去面壁了（可能你能用各种库、框架能写出来，但是等你需要调试 bug，分析问题，就会捉襟见肘）。你也可能在心里嘀咕，上来就写代码，还是面试么？可以说代码是工程师最主要的产出，看着候选人编码能让你熟悉他的思考方式、编码风格、代码习惯，很容能看出来是不是“对味儿”的候选人。

坦率的说，上面的两份代码只能说满足了需求，但是如果做到了以下几点，会有加分：

• 变量命名：节点类的变量，加上 nd 前缀，会更加容易辨识，当然，也有同学习惯借用 jquery 中的 $，关于变量命名的更多内容可以去阅读《可读代码的艺术》；

• 选择符命名：给 CSS 用和 JS 用的选择符分开，给 JS 用的选择符建议加上 js- 或 J- 前缀，提高可读性，还有没有其他好处，请思考；

• 容错能力：应该对节点的存在性做检查，这样代码才能更健壮，实际工作中，很可能你的这段代码会把其他功能搞砸，因为单个地方 JS 报错是可能导致后续代码不执行的，为啥要这样做？不理解的同学可以去看看防御性编程；

• 最小作用域原则：应该把代码段包在声明即执行的函数表达式（IIFE）里，不产生全局变量，也避免变量名冲突的风险，这是维护遗留代码必须谨记的。

下面是综合上面四点的改良版（只针对第1份代码）：

在候选人给出代码之后，笔者常顺便追问：选取节点是否有其他方法？还有哪些？这个问题留给你自己。

二、追问1：如何绑定事件？

现在页面上有了内容，接下来添加交互。问题：要当每个li元素被单击的时候 alert 里面的内容，该怎么做？部分候选人不假思索地给出如下代码：

亦或是把监听事件改为以下：

如果你对闭包和作用域理解没问题，就很容易发现问题：alert 出来的内容其实都是 3，而不是每个 li 的文本内容

上面两段代码都不能满足需求，因为 i 和 ndItem 的作用域范围是相同的。使用 ES6 的块级作用域能把问题解决：

而熟悉 addEventListener 文档的候选人会给出下面的方法：

因为 EventListener 里面默认的 this 指向当前节点，比较喜欢使用箭头函数的同学则需要格外注意，因为箭头函数会强制改变函数的执行上下文。笔者的判断标准是到这里算及格，你及格了么？

聊到这里，笔者有时候还会追问：绑定事件除了 addEventListener 还有其他方式么？如果使用 onclick 会存在什么问题？

三、追问2：数据量变大之后？

貌似上面的问题都没啥挑战，别着急，难度继续增加。如果要插入的 <li> 是 300 个，该怎么解决？

部分同学会粗暴的把循环终止条件修改为 i < 300，这样没有明显的问题，但细想你会发现，在 DOM 中注册的事件监听函数增加了 100 倍，有更好的办法么？读到这里你肯定已经想到了，对，就是事件委托（英文 Event Delegation，亦称事件代理）。

使用事件委托能有效的减少事件注册的数量，并且在子节点动态增减是无需修改代码，使用事件委托的代码如下：

如果你不知道事件委托是什么、实现原理是什么、使用它有什么好处，请花点时间去研究下，能让你写出更好的代码，遇到没听过事件委托的候选人我会追问“标准 DOM 事件的发生流程”，如果熟悉，再引导他理解事件委托，直到写出代码，这个过程能看出来候选人思维是否灵活。

回到正题，相当部分的代码在数据量变大之后容易出各种问题。如果要在 ul 中插入 30000 个 li，会有什么问题？代码需要怎么改进？几乎可以肯定，页面体验不再流畅，甚至会出现明显的卡顿感，该怎么解决？

出现卡顿感的主要原因是每次循环都会修改 DOM 结构，外加大循环执行时间过长，浏览器的渲染帧率（FPS）过低。而实际上，包含 30000 个 li 的长列表，用户不会立即看到全部，大部分甚至根本都不会看，那部分都没有渲染的必要，好在现代浏览器提供了 requestAnimationFrame API 来解决非常耗时的代码段对渲染的阻塞问题。

综合上面的分析，可以从减少 DOM 操作次数、缩短循环时间两个方面减少主线程阻塞的时间。减少 DOM 操作次数的良方是 DocumentFragment；而缩短循环时间则需要考虑使用分治的思想把 30000 个 li 分批次插入到页面中，每次插入的时机是在页面重新渲染之前。由于 requestAnimationFrame 并不是所有的浏览器都支持，Paul Irish 给出了对应的 polyfill，这个 Gist 也非常值得你学习。

下面是完整的代码示例：

读到这里的同学，应该已经理解这一节讨论的要点：大批量 DOM 操作对页面渲染的影响以及优化的手段，性能对用户来说是功能不可分割的部分。

四、追问3：DOM 树的遍历？

数据结构和算法在很多人前端同学看来是没啥用的东西，实际上他们掌握的也不好，但不论前端还是后端，扎实的 CS 基础是工程师必备的知识储备，有了这种储备在面临复杂的问题，才能彰显出工程师的价值。JS 中的 DOM 可以天然的跟树这种数据结构联系起来，相信大家都不陌生，比如给定下面的 HTML 片段：

对这颗 DOM 树，期望给出广度优先遍历（BFS）的代码实现，遍历到每个节点时，打印出当前节点的类型及类名，例如上面的树广度优先遍历结果为：

这要求候选人对 DOM 树中节点关系的表示方式比较清楚，关键属性是 childNodes 和 children，两者有细微的差别。如果是深度优先的遍历（DFS），使用递归非常容易写出来，但是广度优先则需要使用队列这种数据结构来管理待遍历的节点，读到这里，请你找出纸笔，思考 1 分钟，看能不能自己写出来。

下面给出一种参考的实现，代码比较简单，就不多做解释：

如果你对树和树的遍历理解不清，请仔细看上文的外链。最后，再追问一个问题，如果要在打印节点的时候输出节点在树中的层次，该怎么解决？

五、总结和思考题

本文以基本的 DOM 操作为出发点，接下来聊到事件绑定，和渲染性能优化，最后聊到工程师避不开的数据结构和算法。如果你是面试官，你会怎么跟候选人聊？如果你想学好 DOM，只看这篇文章远远不够…..

本文转自以下文章，十分感谢：

破解前端面试（80% 应聘者不及格系列）：从 DOM 说起