刚入坑Vue不到一个月，为了开发一个能跨平台的桌面App，千挑万选之下，最终选了Quasar这套框架，觉得各方面都很适合，内置支持Electron，UI样式也很不错，于是乎就开工做了起来。

顺晟科技：

这样就解决了组件挂载后，computedLimits 无法感知 $el 改变并重算的问题了，经过测试，效果完全符合预期。

接下来就是想办法让这个 limits2 属性起效了。看了下QSplitter的源码，发现它实际上使用的是一个计算属性 computedLimits 来做最终的处理：

https://gitee.com/fictiony/mysplitter

写到这里，这个扩展分隔条组件才算是真正完成了我预期的目标（此处应有掌声:joy:）。

在百度无果的情况下，我打算靠猜。先想了下如果让我自己来设计一个计算属性的响应重算逻辑，我会怎么去设计？我大致想出了两种方案：

由于QResizeObserver组件本身就会在挂载时抛出 resize 事件，而我们的 resize 事件处理函数中又已经进行了 computedLimits 的强制重算和 value 的矫正，于是 beforeCreate 和 mounted 这两个钩子函数也都可以去掉了，简直不要太爽！赶紧测试一下看看——完全OK，毫无bug！

纳尼？！说好的计算属性会自动感知计算函数所涉及的组件属性值改变，并重新计算的呢？是我人品不好，还是我打开的方式有问题？带着疑问，我反复测试了半天，也搜了半天参考帖子，仍然没有头绪，奇了怪了。

如上所见，每个计算属性都在 _computedWatchers 下有一个同名的监视器（Watcher）对象，而这个监视器就是用来监视所有依赖的响应式属性的改变的，同时也记录了计算属性的缓存值（value）和是否需要重算的标记（dirty）。所以，只需要手动将同名监视器的重算标记设为 true ，就可以强制计算属性重算了（或者也可以调用监视器的 update 方法，效果是一样的）。下面就是我添加的 mounted 钩子函数：

于是我就想要重载这个属性，增加对 limits2 的判断。即当定义了 limits2 时，根据 limits2 来计算，否则保持原样。

我惊喜的发现，基类和继承类组件的选项表，都被妥妥的的安排在了继承类的构造函数上，还自动进行了合并。这不就好办了嘛，直接拿 QSplitter.options 下相应位置的方法来用就欧了。于是重载后的 computedLimits 就被我写成了这样：

为了证实我的猜测，我又仔细的撸了一遍Vue的源码（此处省略数小时），总算大致搞明白了Vue里对于计算属性的处理逻辑，还真和我猜想的第2种方案基本类似，不过在具体实现上有很多高明之处，这里就不展开来细说了。这里我们只需要知道，Vue的计算属性也是采用运行时动态标记要监视的响应式属性的，因此如果计算函数在运行时没有执行到包含某个响应式属性的分支流程，那么这个属性就不会被该计算属性所监视，也就无法感知到它的改变了。看来，计算属性虽然很智能，但用起来也要很小心呀，一个不当心，可能就掉坑里了，233333。

不过虽然看上去好像一切都满意了，但别忘了，limits2 和 limits 不一样的地方在于，它是会受DOM元素大小影响的，一旦DOM元素大小改变了（这很常见，窗口缩放一下就会遇到，或者分隔条嵌套使用也会），而其他相关属性却没变时，computedLimits 可不会自动重算，于是就会出现分隔条拖拽范围不正确的bug。因此，我还需要增加 resize 事件的处理。

这是我遇到的第三个坑，也是卡我时间最久的一个，

对应的事件处理函数就简单多了，和前面写过的 mounted 几乎一样，代码如下：

好了，这又是个百度不到的万年大坑，我好难啊~

大坑：

由于我要增加的功能，是能够指定分隔条两侧区域的最小像素范围，而QSplitter组件本身已经有一个 limits 属性了，我并不想覆盖它的功能，因此我参考了QSplitter的源码，增加了一个 limits2 属性，定义如下：

这种方式是利用了Vue组件注册时自动实现的继承处理，而且并不要求必须用 Vue.extend(options) 的方式直接定义成组件类，而是可以和.vue单文件模板一样，只定义成选项表的形式（也就是单纯的 options 对象）。我认为这样更为统一规范一些，因此最终我选用的就是这种方法。而且这样带来的额外好处是全局注册的时候可以直接取 name 字段作为组件名，也可以很灵活的进行定制化处理（因为本身就只是个options对象，只需要用 { ...options, ... } 这样的方式就可以实现定制扩展）。

由于 vm.$scopedSlots.default 是一个返回虚拟节点列表的函数，因此我可以直接将其替换成新的函数，并将原函数和要注入的虚拟节点列表都记下来，以便在新函数执行时重新进行组合。考虑到注入插槽的操作可能在扩展组件时经常会用到，为了能更好的复用，我就把它写成了通用的方法： injectSlot(vm, slot, id, nodes, before)（其中 id 和 before 参数是为扩展性目的而加，涉及了一些常用的列表注入技巧，此处按下不表）。同时为了调用方便，我还把它直接加到了 Vue.prototype 下面（规范起见，函数名前多加一个$，以免命名冲突），变成组件的成员方法。这样调用时就无需再 import 了，且还能省去一个 vm 参数，直接写成 this.$injectSlot(slot, id, nodes, before) 即可。具体代码这里就不贴了，感兴趣的童鞋可以去组件源码中查看。

没说的，还是得要从Vue源码入手去找解决方案。于是我找到了计算属性的初始化方法：

于是，渲染时注入QResizeObserver组件的 render 方法就可以这么写了：

加了之后，mounted 钩子函数里的那句 this._computedWatchers.computedLimits.dirty = true 也就可以去掉了。测试了一下，初始状态、拖动、动态设置属性，都没啥问题。

由于并不是特别赶工，本着解决问题就是更好的学习方法的思路，我开始了对QSplitter组件进行二次开发的研究。

不过目前还并不算很完美，毕竟还是有一些瑕疵的。比如当窗口缩小时，分隔条由于受范围限制而被动矫正了位置，这个位置就会被保留下来，导致窗口放大回原来大小时，分隔条无法回到原来的位置，这在使用体验上会带来些许问题。当然，这些都属于优化的范畴了，这里就不再展开讨论，裹脚布已经够长的了。

老实说，这个坑我并不算真正填平了，我只是针对QSplitter组件的 render 方法做了一个针对性的解决方案。考虑到QSplitter组件本身提供了4个插槽，其中 default 插槽正好用来加入QResizeObserver组件。不过分析了下 render 的代码发现，通过简单的函数注入或列表注入方法，似乎是行不太通的，那么就只能劫持插槽本身了，也就是 vm.$scopedSlots.default 。

Vue官方API文档中只提到了 Vue.observable(object) 接口，用来将一个对象的内部属性转为响应式的，却没有提到如何将单个属性转为响应式的接口。不过这难不倒我，毕竟我手上有Vue源码。只需要挖一下 observable 的实现代码，就可以找到一个名为 defineReactive 的接口（这个接口也能百度到，但参考资料不多），它可以通过 Vue.util.defineReactive(obj, key, val, customSetter, shallow) 的格式来调用。我只需要用到前两个参数就够了，后面的参数不用管它。由于要在 $el 改变前，也就是组件挂载前就将它转为响应式属性，因此更好在 beforeCreate 钩子函数中调用，具体如下：

这种方式虽然写起来很简洁，也方便添加额外的参数和子元素，但漏洞比较多，不能算是一种真正的继承，而更像是把基类组件打了个包（叮咚，有你的快递~），在Vue调试器里会多出一层组件节点。另外对于插槽的处理也不友好，需要手动全部重新封装一遍传进去。因此我不是很推荐使用这种方法，它可能会破坏组件的接口和数据流向，产生不可预知的bug。

可是测试了下发现，在指定了 limits2 后，范围限制并没有起效，即使反复修改 limits2 也一样，再查了下 computedLimits 的值，竟然始终都是原始默认值！不信邪的又在计算函数开头加了一句日志打印，发现它居然只在组件创建时执行了两次，后面就不再执行了。这说明这个计算属性根本没有响应 limits2 的变化！

原文链接：扩展分隔条（MySplitter）组件 - Qusar Framework 中文社区

网上看了好多资料都提到了三种继承方式：

由于 <div> 元素并不能在大小改变时抛出 resize 事件，因而需要用一些变通的方法来解决。好在Quasar早已经考虑到了这个问题，提供了 QResizeObserver 组件专门来解决。不过对于我这个继承的组件来说，情况就有点复杂了。因为并没有现成的 <template> 定义可以供我方便的嵌入额外组件，而若要通过重载 render 方法来实现嵌入，又没办法直接嵌入组件本身，只能手动合并组件渲染生成的虚拟节点列表。对于我这个Vue新手来说，这着实算是个难度颇高的任务了。

Quasar的组件库虽然已经算很成熟很全面了，但实际应用中也难免碰上一些不足之处。比如在用到分隔条（QSplitter）组件的时候，就发现它只支持针对单边区域的更大最小限制。而通常App中需要的却是对两边区域都有最小限制（比如VSCode这样，左边功能区不小于170px，右边编辑区不小于300px），更大限制倒很少用到。虽然在百分比模式（unit=’%’）下，若想要限制右侧区域的下限为10%，可以通过设置左侧区域的上限为90%来实现，但在像素模式（unit=‘px’）下，就没有代替方案了。更何况通常App里我们希望限制的下限必须是像素为单位的（不然大小不确定），这就很尴尬了。

这种方式网上很少深入去讲，只放个很简单的例子来说明，甚至基本上讲的都是以 Vue.extend(<基类>) 的方式来调用，而不是 <基类>.extend(options) 。结果生成的只是基类的一个拷贝，而想要加入扩展内容，只能在new实例的时候传入额外的 options 选项表来实现（还特别强调了要用 propsData 来代替 props）。那我要这个“继承”类来干嘛呢？还不如直接new一个基类的实例，不也一样可以传options么？所以网上大多数讲的都是错的，用 <基类>.extend(options) 才是正确的写法。但需要注意的是，用 extend 函数来定义组件（无论是否继承），返回的是组件的构造函数，而不是组件定义的选项表（像.vue单文件模板那样）。

最后，奉上完整的组件源码，希望能给大家带来启发和帮助。

碰上第四个坑了，

恰巧，我的计算函数里正好存在IF分支，在组件未挂载时（此时 $el 尚无取值）会绕过对 limits2 的取值。那么会不会就是因为这个原因，导致后面 limits2 的改变都无法被感知到了呢？

等一下，为什么 $el 不是一个响应式属性呢？能吗？不能吗？我也不知道，也许Vue的作者有他自己的理由，至少目前我是不了解的。但这并不妨碍我把它变成一个响应式属性。因为这样一来，如果有多个计算属性都依赖 $el 的判断时，就可以不用在 mounted 里面加一堆难看的 this._computedWatchers.xxx.dirty = true 了。至于把 $el 设为响应式属性会带来什么不好的副作用，暂时我还没有发现。

我找遍了网上的资料，完全找不到一个调用Vue基类组件方法的例子，这不科学！既然没的参考，于是我只好自己研究。其实说白了也不难，无非就是 console.log(QSplitter) 一下，在开发者工具里看看里面都有些啥。一看发现它并不是个对象，而是个构造函数，于是继续点进去看源码，然后就看到Vue的源码里去了:sweat_smile:：

由于还是个Vue新手，虽然已经啃了几周的文档，但实际操作起来还是碰到了各种问题。

碰到的个坑，就是

决定下来用第二种方式继承之后，我就开始着手编写我的扩展分隔条（MySplitter）组件了：

虽然找到了问题的原因，但想要解决也不是那么容易。毕竟我们的计算函数里，对于 $el 的判断是必不可少的，而 $el 本身又不是一个响应式属性，并不会因为组件挂载了之后 $el 变了，就能让 computedLimits 感知到并且重算。好在组件挂载是有 mounted 钩子函数的，那么能不能在组件挂载时，强制 computedLimits 重算呢？

结果第二个坑来了，