vue的组件封装选择个人之见

  现在的编程开发中，组件化开发越来越常态化，并且许多人在实际开发中直接一开始就是封装一大堆的各种组件，然后再把各种组件按照需求往主体中进行各种加塞。
         其实，我们在实际开发中，很多时候接到的需求其实是对已经存在的项目进行优化、拓展或者说升级，这种已经有的项目框架部分已经决定好了你接下来的主要技术栈，如果脱离了现在已经投入项目适用的技术栈来进行后面拓展功能开发的话，很容易存在各种问题，比如说：页面主体风格，框架样式冲突，各功能页面交互...所以，一定要综合考虑这些问题之后再决定用什么技术栈进行开发。
         总体而言，原生js是能很愉快并且很顺利的兼容其他绝大部分前端框架的，现在的主体前端框架在同技术栈中只需要注意部分组件的版本冲突也能很顺利的进行后续开发。
         接下来就是组件开发的选择与控制。在之前的开发中，我们绝大多数人很喜欢将所有的功能都集中在主体页面，把一些无关紧要的板块或者功能模块封装成组件放一边。**但是假如我们遇到这种情况怎么处理呢：我有个页面，在该页面有四五个数据表格，每个数据表格内容不同，功能需求也不同**，但总体都离不开增删改查，一个表格的增删改查不算多，但四个五个或者更多的时候，那代码的行数绝对会是个很感人的数字。 
         我们还有种情况：一开始就将各种功能直接进行组件化封装，但经常会遇到在同一个页面调用多个组件的时候各种参数多的让人欲仙欲死，如果组件的层级再多那么一丢丢，父子组件之间、兄弟组件之间，三级组件和一级组件之间、然后子组件的子组件的子组件....那其中的参数传递与处理绝对会让你感天动地！
         经过大大小小的各种项目折磨之后，就个人总结而言，觉得组件不要太多，够用就好，组件也不要特意去往少里控制，保证每个页面文件的代码行数在最适合维护的量就好。因为我们的项目不是一投产就不管不问了的，经常会在投产之后进行各种维护与修改调整，如果一个某个页面文件的代码行数过多，就会增加代码的维护难度；但如果组件过多，也容易在后面维护的时候造成参数传递出问题。
          因此，我们可以遵循如下规则：在保证参数传递尽量简洁且数量少的情况下，进可能的进行组件化开发；如果参数传递比较复杂并且数据处理麻烦的话，就尽量在功能的主体页面上进行开发，不要刻意去追求组件化封装来增加自己的工作量。