Element-ui中元素滚动时el-option超出元素区域的问题

Element-ui中的滚动与el-option超越界限问题：长沙网络推广的经验分享

今天，我想和大家分享一个在使用Element-ui时遇到的常见问题，以及如何巧妙解决的经验。长沙网络推广在这方面有一些独到的见解，或许能给大家带来一些启示。

一、复现场景

让我们模拟一下这个场景。当你滚动页面时，el-option元素超出了它的容器区域，这种情况是如何发生的呢？让我们一起来看看。

二、问题分析

我们来深入了解一下背后的原因。我们把选项区域称为popperEl。

1. popperEl的z-index较大，导致它覆盖在其他元素之上。

3. 当按下鼠标并移动滚动条时，popperEl并没有隐藏的逻辑触发，因为它是在mouseup事件中处理的。

4. 而且，popperEl并不监听滚动事件，这也是无法监听的，因为没有必要。

三、解决方案

面对这个问题，我们该如何解决呢？

方案一：

最初，我尝试通过CSS来解决这个问题。我试图给Select下拉框添加类名，然后通过CSS来调整样式。这个方案在某些特定场景下才有效，并不是万能的。如果有朋友在这方面有成功的经验，请不吝赐教。

方案二：

另一种尝试是监听根元素的scroll事件，并希望通过事件冒泡来解决。遗憾的是，scroll事件并不支持冒泡，这一方案并未如愿。尽管event.bubbles为false，但我们仍然可以尝试其他方法来解决这个问题。或许存在其他途径让我们能够捕捉到滚动事件并对el-option的位置进行动态调整。各位开发者朋友们，你们是否遇到过类似的问题？是否有更高效的解决方案呢？期待你们的分享和指点。

长沙网络推广在此也呼吁大家，共同，共同进步，一起为Element-ui的使用体验贡献智慧。希望这篇文章能给大家带来启发和帮助。如果您有任何疑问或建议，请随时与我们交流。让我们一起学习，一起成长！

方案三之旅

在element-ui的select.vue文件时，我发现了控制popperEl显示与隐藏的关键在于visible和emptyText这两个实例属性。显然，emptyText是固定的，我们的操作重点要放在visible上。以下是相关的源码片段：

全局搜索visible属性时，我发现了handleClose方法，它负责将visible设置为false。这为我指明了方向，我顺着这个线索找到了另一个关键部分：

这里使用到了v-clickoutside指令，原来当点击其他区域时，popperEl会自动关闭的奥秘就在这里。结合方案二的灵感，我给出了以下代码。

为了解决这个问题，我创建了一个名为fackClickOutSide的混入（mixin），位于src/mixins/fackClickOutSide.js文件中。它利用mousedown和mouseup事件来模拟点击操作。当在除el-select元素以外的区域进行点击或滚动操作时，会触发fakeClickOutSide函数，使popperEl关闭。

使用姿势：建议在根组件上混合该混入，当然你也可以在需要的组件上混合（虽然不太建议，但性能损耗应该不大）。在App.vue文件中引入并使用这个混入。

测试：经过测试，该方案在常规基础用法和自定义模板用法（没有嵌套标签）中表现完美。如果自定义模板中存在嵌套标签，需要在这些标签上添加特定标记，以便在事件处理中进行判断。

仍存在一些问题需要注意：

1. 鼠标滚轮事件的回调没有做节流处理，但由于有锁且滚轮事件触发频率不高，性能消耗并不大，因此暂时没有进行节流处理。

2. 在鼠标滚轮事件的回调中，通过判断event.target是否在popperEl元素内部的方法可能不太靠谱且效率不高。同样，在mousedown事件里判断是否是el-select元素的方法也存在隐患。后期需要寻找更可靠的解决方案。

3. 对于自定义模板中的嵌套标签问题，目前的解决方案是手动添加标记并在事件处理中进行判断。这种办法对于已完成的模板无效，只能进行修改。虽然考虑过使用递归向上查找，但效率不高且性能消耗大，且自定义el-option模板的情况在现阶段的业务中几乎不存在。

要感谢一位大佬长期以来的帮助。他的指导让我在这个项目中取得了不小的进步。以上就是我对这个方案的详细解读和测试反馈。