今天跟导师一起做联调的时候，简单讨论了一些关于组件封装的想法。
哦莫，我发现我做封装，总是陷入一个误区，觉得把多个页面公共的部分单拎出来，封个组件，然后在这个组件里统一进行业务处理，这就是封装了。其实越写到后边越觉得这是在“[便便]山”上堆“[便便]”，举个例子来说（后台管理系统）：
之前的封装思路：
AdvancedSearch：高级搜索组件
给AdvancedSearch组件传递dataType参数，用来告诉AdvancedSearch是谁在使用它，然后在AdvancedSearch里面根据dataType来选择要展示的表单组件；且搜索完之后，在AdvancedSearch中直接发起请求来获取表格数据，然后把表格数据传递给使用它的组件。
这样写的弊端：
1、不灵活。将具体业务逻辑和数据请求放在 AdvancedSearch 组件中会导致该组件与特定的数据源和业务逻辑紧密耦合，限制AdvancedSearch组件的复用性和灵活性。
2、代码重。AdvancedSearch处理业务太多了，它不应该承担过多的职责，应该专注于表单的展示和搜索功能。
3、dataType传着传着就传乱了，因为太多页面要使用AdvancedSearch。
换一种思路：
1、AdvancedSearch组件里要满足所有使用它的页面，所需要的表单组件。使用AdvancedSearch的父组件，给AdvancedSearch传递一个数组，数组里面是它想要使用的组件名，这样如果后续需要添加或者删除，就只用修改数组即可。
2、表单提交时，AdvancedSearch组件给父组件传递表单填写的内容，发起请求要在父组件里做。
这样写的弊端：
1、将表单组件的选择和配置信息交给父组件管理会增加父组件的复杂度，同时也会影响到子组件的复用性和可维护性。
2、如果需要将 AdvancedSearch 组件嵌套在多个父组件中使用，就会出现代码重复和冲突的问题，因为每个父组件都需要管理表单组件的选择和配置信息，而且还需要处理表单提交请求的逻辑。
跟导师交流后get到的重点：
1、布局层，从整体的页面布局来拆分。这一层负责整体的页面布局结构，但不涉及具体的业务逻辑和数据展示。
2、框架层，封装体要服务好上层，且具有灵活性（使用插槽）。在这一层就是来封装AdvancedSearch组件的。
3、业务层，负责处理具体的业务逻辑和数据展示。在这一层可以引入框架层的组件，同时负责与后端进行数据交互，并将数据传递给框架层组件进行展示。
4、这三层之间的数据流向主要是：从业务层到框架层，以及从框架层到业务层。布局层负责整体的布局控制，并可以向下传递需要展示的内容。
时间原因，没有深入请教，不过大概的思路get到了。过两天有时间，再找前端大佬求教一番，整理一篇更详细的。或许，你能给我讲讲你是怎么封装的嘛？
我现在认为，搞技术，做开发，最重要的是思维。实现功能的代码，大家都会写，但是如何优雅巧妙的写，值得深思。
网友评论