1.问题形容：在重构零碎中一个功能模块的时候遇到的一些问题
（1）代码拷贝重大，同样的构造写&办法写了二十多遍。
（2）明明曾经封装好某个性能组件，不同的人开发时又稀里糊涂的写了一顿。
2.重构时遇到的问题：
（1）单向数据流的问题：Vue心愿子组件中注册的props只能被应用不能被批改。
（2）大量应用$parent隐式的调用父组件中的数据或办法，导致代码可读性很差。
（3）将父组件中的公共办法抽离到一个class中（调用的中央不对会导致一些问题）、或者通过export一一导出，同样可读性、可维护性、扩展性都不怎么样。其实这就是组件封装的不合理，既然办法是通用的为什么不能间接在封装组件的时候将办法写好？而要通过$parent调用，而后再抽离进来以缩小代码量？？？
（4）在子组件中大量的注册props，但注册的有些属性是须要被批改的（默认会报警）。而后通过$emit的形式批改父组件中的这个值再映射到子组件，尽管解决了报警，但代码量会剧增。同样不合理，尽管也能够通过将props写入到子组件的data、computed中的形式解决。然而我感觉，一个公共组件大量的注册父组件中的属性原本就是不合理的，说白了就是设计上的缺点。
3.从新设计&正当封装：
（1）子组件中须要用到父组件中的很多属性，并且用到的某些属性又须要在子组件中被批改。很显著通过props注册的形式是不合乎单向数据流的理念的。所以咱们只在子组件中注册一个值，用来确定以后是在哪个父组件下，而后通过这个值在一个封装好的js中获取对应父组件的一堆属性。这样既不会扭转注册的props也能将多个父组件的属性放到一起不便对立治理，还能更好的对不同的父组件进行扩大，同时大量的升高了代码量。
（2）把公共办法封装到公共组件中，何必再进行一次抽离。
（3）只封装雷同的局部。如果多个页面有重合的构造，那么重合的局部应该当成公共局部封装到一个组件里。而不同的局部只须要在父组件中与公共组件进行组合即可。为什么不能把不同的局部也组合到公共组件里？我集体了解，这样做代码的耦合度会很高，如果前期进行改变，则解耦又会很麻烦。
4.局部代码：
Common.vue
Options.js
Father.vue
5.补充：
还有一种解决单向数据流报警的办法就是传个对象，例如代码中的queryForm。当然queryForm也能够对应写到options.js中。
6.总结：
在重构我的项目的时候询问了一个新手，他说好的程序好在它的设计，高级的人高级在会他会设计。所以综合我在重构时遇到的一些问题，好的设计的确nb！还须要持续致力啊。。。如果有更优的做法还心愿可能揭示一波~感激！