Vue组件设计学习笔记，持续记录

关于组件化组件化思想并不是前端独有的，但却是前端技术的延伸任何软件开发过程，或多或少都有那么一些组件化的需求。

1.组件化的特点

每个组件对应一个目录，组件所需的各种资源都在这个目录下就近维护；（最具软件工程价值）页面上的每个独立的可视/可交互区域视为一个组件；由于组件具有独立性，可以自由组合；页面是组件的容器，负责组合组件形成功能完整的界面；当不需要某个组件，或者想要替换组件时，可以整个目录删除/替换分子是由原子组成的，分子分成原子，原子也可以重新组合成新的分子一个界面是由独立的分子组件搭建而成，分子组件由原子元件构成，这些原子可通过不同的组合方式，组成新分子组件，继而重组构成新的界面

组件设计的原则组件化方案下，我们需要具有组件化设计思维，它是一种【整理术】帮助我们高效开发整合

标准性任何一个组件都应该遵守一套标准，可以使得不同区域的开发人员据此标准开发出一套标准统一的组件
独立性描述了组件的细粒度，遵循单一职责原则，保持组件的纯粹性，属性配置等API对外开放，组件内部状态对外封闭，尽可能的少与业务耦合
复用与易用 UI差异，消化在组件内部（注意并不是写一堆if/else），输入输出友好，易用。追求短小精悍，Single Point Of Truth法则，就是尽量不要重复代码，出自《The Art of Unix Programming》；

避免暴露组件内部实现，避免直接操作DOM，避免使用ref，使用父组件的 state 控制子组件的状态而不是直接通过 ref 操作子组件。

入口处检查参数的有效性，出口处检查返回的正确性。

无环依赖原则(ADP) 4.1 环形依赖组件间耦合度高，集成测试难一处修改，处处影响，交付周期长因为组件之间存在循环依赖，变成了“先有鸡还是先有蛋”的问题。

4.2 避免环形依赖沿着逆向的依赖关系即可寻找到所有受影响的组件，创建一个共同依赖的新组件。

稳定抽象原则(SAP)

组件的抽象程度与其稳定程度成正比一个稳定的组件应该是抽象的（逻辑无关的）一个不稳定的组件应该是具体的（逻辑相关的）为降低组件之间的耦合度，我们要针对抽象组件编程，而不是针对业务实现编程。

避免冗余状态

如果一个数据可以由另一个 state 变换得到，那么这个数据就不是一个 state，只需要写一个变换的处理函数，在 Vue 中可以使用计算属性如果一个数据是固定的，不会变化的常量，那么这个数据就如同 HTML 固定的站点标题一样，写死或作为全局配置属性等，不属于 state 如果兄弟组件拥有相同的 state，那么这个state 应该放到更高的层级，使用 props 传递到两个组件中

合理的依赖关系父组件不依赖子组件，删除某个子组件不会造成功能异常
扁平化参数除了数据，避免复杂的对象，尽量只接收原始类型的值
良好的接口设计

把组件内部可以完成的工作做到极致，虽然提倡拥抱变化，但接口不是越多越好如果常量变为 props 能应对更多的场景，那么就可以作为 props，原有的常量可作为默认值。如果需要为了某一调用者编写大量特定需求的代码，那么可以考虑通过扩展等方式构建一个新的组件。保证组件的属性和事件足够的给大多数的组件使用。 API尽量和已知概念保持一致

组件分类组件最大的不稳定性来自于展现层，一个组件只做一件事，基于功能做好职责划分。

基础组件（ui组件库） antdelement-ui
容器型组件（业务角度，非代码角度）一个容器性质的组件，一般当作一个业务子模块的入口，比如一个路由指向的组件。

容器组件内的子组件通常具有业务或数据依赖关系集中/统一的状态管理，向其他展示型/容器型组件提供数据（充当数据源）和行为逻辑处理（接收回调）如果使用了全局状态管理，那么容器内部的业务组件可以自行调用全局状态处理业务业务模块内子组件的通信等统筹处理，充当子级组件通信的状态中转站模版基本都是子级组件的集合，很少包含DOM标签辅助代码分离

&lt;!-- 搜索区域 --&gt;
&lt;Search v-show=&#34;toggleFilter&#34; :form=&#34;form&#34;/&gt;
&lt;!--展开收起区域--&gt;
&lt;Toggle :toggleFilter=&#34;toggleFilter&#34;/&gt;
&lt;!-- 列表区域--&gt;
&lt;List :data=&#34;listData&#34;/&gt;

</div> </template>

展示型（stateless）组件主要表现为组件是怎样渲染的，就像一个简单的模版渲染过程。

只通过props接受数据和回调函数，不充当数据源可能包含展示和容器组件并且一般会有Dom标签和css样式通常用props.children(react) 或者slot(vue)来包含其他组件对第三方没有依赖（对于一个应用级的组件来说可以有）可以有状态，在其生命周期内可以操纵并改变其内部状态，职责单一，将不属于自己的行为通过回调传递出去，让父级去处理（搜索组件的搜索事件/表单的添加事件）

&lt;el-table
  :data=&#34;data&#34;
  :class=&#34;{&#39;is-empty&#39;: !data ||  data.length ==0 }&#34;
  &gt;
  &lt;el-table-column
    v-for = &#34;(item, index) in listItemConfig&#34;
    :key=&#34;item + index&#34; 
    :prop=&#34;item.prop&#34; 
    :label=&#34;item.label&#34; 
    :width=&#34;item.width ? item.width : &#39;&#39;&#34;
    :min-width=&#34;item.minWidth ? item.minWidth : &#39;&#39;&#34;
    :max-width=&#34;item.maxWidth ? item.maxWidth : &#39;&#39;&#34;&gt;
  &lt;/el-table-column&gt;
  &lt;!-- 操作 --&gt;
  &lt;el-table-column label=&#34;操作&#34; align=&#34;right&#34; width=&#34;60&#34;&gt;
    &lt;template slot-scope=&#34;scope&#34;&gt;
      &lt;slot :data=&#34;scope.row&#34; name=&#34;listOption&#34;&gt;&lt;/slot&gt;
    &lt;/template&gt;
  &lt;/el-table-column&gt;
  &lt;!-- 列表为空 --&gt;
  &lt;template slot=&#34;empty&#34;&gt;
    &lt;common-empty /&gt;
  &lt;/template&gt;
&lt;/el-table&gt;

</div> </template> <script> export default {

props: {
    listItemConfig:{ //列表项配置
    type:Array,
    default: () =&gt; {
        return [{
            prop:&#39;sku_name&#39;,
            label:&#39;商品名称&#39;,
            minWidth:200
        },{
            prop:&#39;sku_code&#39;,
            label:&#39;SKU&#39;,
            minWidth:120
        },{
            prop:&#39;product_barcode&#39;,
            label:&#39;条形码&#39;,
            minWidth:120
        }]
  }
}}

} </script>

业务组件通常是根据最小业务状态抽象而出，有些业务组件也具有一定的复用性，但大多数是一次性组件

5.通用组件可以在一个或多个APP内通用的组件

UI组件特点：复用性强，只通过 props、events 和 slots 等组件接口与外部通信

&lt;img src=&#34;/images/empty.png&#34; alt&gt;
&lt;p&gt;暂无数据&lt;/p&gt;

</div> </template>

逻辑组件不包含UI层的某个功能的逻辑集合

8.高阶组件（HOC）高阶组件可以看做是函数式编程中的组合可以把高阶组件看做是一个函数，他接收一个组件作为参数，并返回一个功能增强的组件

高阶组件可以抽象组件公共功能的方法而不污染你本身的组件比如 debounce 与 throttle

9.组件协同 10.容器/展示组件引入容器组件的概念只是一种更好的组织方式。

容器组件专门负责和store通信，把数据通过props传递给展示组件，展示组件如果数据需要更新，需要传递回调给容器组件，在容器组件中执行具体操作（业务逻辑）来获取更新结果展示型组件不再直接和store耦合，而是通过props接口来定义所需的数据和方法，复用性与正确性更能保证展示型组件直接和store通信的话，那么一个展示型组件就会收到限制，因为你在store里面的字段已经限制他的使用次数和使用的位置各司其职，不易出错，即使出错，也能快速定位问题

10.1 引入容器组件的时机优先考虑展示组件，当你意识到有一些中间组件不使用它继承的props而是转而传递给他们的子级，每次子级组件需要更多数据时，你都需要重新调整这些中间组件，那么，这时候就要考虑引入容器组件

容器组件和展示组件的区别并没有被严格定义，它们的区别不在技术上而是目的性上。

容器组件倾向于有状态，展示组件倾向于无状态，这不是硬性规定，它们都是可以有状态的，不要把分离容器组件和展示组件当做教条，如果你不确定该组件是容器组件还是展示组件，就暂时不要分离，写成展示组件，也许是为时尚早。别着急！这是一个持续的重构过程，不用试图一次就把它做好，习惯这种模式就会培养起一种直觉，知道何时引入容器就像你知道何时封装一个函数那样儿进行组件职能划分的利弊

11.进行组件职能划分的利弊 11.1 优点

更好的关注分离，用这种方式写组件，你可以更好的理解你的app和你的ui，甚至会逐渐形成你自己的开发套路复用性高，一个组件只做一件事，解除了组件的耦合带来更高复用性，它是app的调色版，设计师可以随意调整它的ui而不用改变app的逻辑这会强制你提取“布局组件”，达到更高的易用性提高健壮性可测试性，组件做的事情更少了，测试也会变得容易，容器组件不用关心UI的展示，只关心数据和更新，展示组件只是呈现传入的props，写单元测试的时候也非常容易mock数据层

11.2 缺点

因为容器组件/展示组件的拆分，初期会增加一些学习成本由于需要封装一个容器，包装一些数据和接口给展示组件，会增加一些工作量在展示组件内对props的声明会带来少量的工作

组件设计的边界

页面层级不宜嵌套超过三层，切勿过度设计超过三层之后可见组件的数据传递的过程就会变得越复杂
组件可否（有必要）再分？

划分粒度的根据实际情况权衡，太小会提升维护成本，太大又不够灵活和高复用性每一个组件都应该有其独特的划分目的的，有的是为了复用实现，有的是为了封装复杂度清晰业务实现组件划分的依据通常是业务逻辑、功能，要考虑各组件之间的关系是否明确，及可复用度如果它只是几行代码，那么最终可能会创建更多的代码来分离它，有必要吗？我这么做的好处是否超过了成本？如果你当前的逻辑不太可能出现在其他地方，那么将它嵌入其中更好，如果需要，你可以随时抽离，毕竟组件化没有终点性能会受到影响吗？如果状态频繁更改，并且当前在一个较大的，关系比较紧密的组件里，为了避免性能受到影响最好抽离出来是否打破了一个逻辑上有意义的实体，倘若抽离的话，这个代码被复用的概率有多大

3.这个组件的依赖是否可再缩减？缩减组件依赖可以提高组件的可复用度

这个组件是否对其它组件造成侵入？封装性不足或自身越界操作，就可能对自身之外造成了侵入，一个组件不应对其它兄弟组件造成直接影响。
这个组件可否复用于其它类似场景中？需要考虑需要适用的不同场景，在组件接口设计时进行必要的兼容
这个组件当别人用时，会怎么想？接口设计符合规范和大众习惯，尽量让别人用起来简单易上手，易上手是指更符合直觉。
假如业务需要不需要这个功能，是否方便清除？各组件之前以组合的关系互相配合，也是对功能需求的模块化抽象，当需求变化时可以将实现以模块粒度进行调整。

落实到具体业务中如何做

划分依据明确组件划分依据，目前是两种

根据业务划分根据技术划分我更多的是根据业务去设计我应用中的组件树，可能会画个草图或xmind，它可以帮我统观全局明确各个组件的边界，内部state的设计，props的设计以及与其他组件的关系（需要回调出去的事件）明确各个组件的定位与职能划分，设计好父子组件、兄弟组件的通信机制搭架子架子有了，开始填空

2.切割模版（页面结构模块化）这是最容易想到的方法，当一个组件渲染了很多元素，就需要尝试分离这些组件的渲染逻辑以掘金页面为例

大体上看，可以分为Part1，Part2，Part3

2.1 初步开发 <template> <div id=“app”>

&lt;div class=&#34;panel&#34;&gt;
  &lt;div class=&#34;part1 left&#34;&gt;
    &lt;!--内容--&gt;
  &lt;/div&gt;
  &lt;div class=&#34;part1 right&#34;&gt;
    &lt;!--内容--&gt;
  &lt;/div&gt;
  &lt;div class=&#34;part1 right&#34;&gt;
    &lt;!--内容--&gt;
  &lt;/div&gt;

</div> </template>

2.2 存在问题[/h3 代码量大，难以维护，难以测试，有些许重复量

[h3]2.3 划繁为简

  &lt;part1 /&gt;
  &lt;part2 /&gt;
  &lt;part3 /&gt;

</div> </template>

好处：同之前的方式相比，这个微妙的改进是革命性的，解决了测试困难，维护困难的问题；问题：没有解决代码重复的问题，这种按模块划分，复用性低

2.4 组件抽象它们有相似的外层，part2和part3更有相似的titlebar，除了业务内容，完全就是一模一样

&lt;header&gt;
  &lt;span&gt;{{ title }}&lt;/span&gt;
&lt;/header&gt;
&lt;slot name=&#34;content&#34; /&gt;

</div> </template>

将part内可以抽象的数据都做成了props，利用slot去做模版那么我们在开发相应Part1，Part2时：

  &lt;part title=&#34;亦舒&#34;&gt;
    &lt;div slot=&#34;content&#34;&gt;----&lt;/div&gt;
  &lt;/part&gt;
  &lt;part title=&#34;兴隆臻园户型&#34;&gt;
    &lt;div slot=&#34;content&#34;&gt;-----&lt;/div&gt;
  &lt;/part&gt;

</div> </template>

更具代表性的示例图：

UI差异在哪里定义？在业务逻辑层处理，首先要明确一点，这些差异并不是组件本身造成的，是你自己的业务逻辑造成的，所以容器组件（父组件）应该为此买单
数据差异在哪里定义？结合组件本身和业务上下文将差异合理的消除在内部

比如part3中，其他的part只有一个类似更多>>的link，但是它却有多个(一居，二居…)

这里推荐将这种差异体现在组件内部，设计方法也很多：

比如可以将link数组化为links；比如可以将更多>>看作是一个default的link，而多余的部分则是用户自定义的特殊link，这两者合并组成了links。用户自定义的默认是没有的，需要引用组件时进行传入。

组件命名规则？组件设计初期，就应该拥有不耦合业务的名字，一个通用的或者说未来可能通用的，要有相对合理的命名，比如 Search，List,尽量不要出现与业务耦合过深的业务名词，通用组件与业务无关，只与自身抽象的组件有关。

在设计组件初期，就应该有这种思想，库通常都想让广大开发者用，在设计组件时，可以降低标准到先做到你的整个APP中通用

组件划分细粒度的考量组件设计规则明明白白写着我们要遵循单一职责原则，这也带来了上文聊过的过度抽象（组件化）的问题，组件抽离的过程就是无限向无状态（展示型）组件无限靠近的过程。

对于组件设计，充分的准备固然，但在现实世界中，切实的结果才是最重要的，组件设计也不要过度设计更不要停滞不前，该做的时候就去做，发现不好就去改有空闲时间就去思考早期不够理想的代码，它可以作为我们向前发展的基础技术在变迁，但组件化的核心并没有改变，目标仍然是在API设计尽可能接近原生的情况下完成复用、解耦、封装、抽象的目标，最终服务于开发，提高效率降低错误率组件化是对实现的分层，是更有效地代码组合方式组件化是对资源的重组和优化，从而使项目资源管理更合理，方便拔插、方便集成、方便删除、方便删除后重新加入这种化繁为简的思想在后端开发中的体现是微服务，而在前端开发中的体现就是组件化组件化有利于单元测试与自测效率对重构较友好新人加入可以直接分配组件进行开发、测试，而非需要熟悉整个项目，可以从一个组件的开发使新进人员比较快速熟悉项目、了解到开发规范你的直接责任可能是编写代码，但你的终极目标是在创建产品

阅读剩余 0%

本站所有文章资讯、展示的图片素材等内容均为注册用户上传(部分报媒/平媒内容转载自网络合作媒体)，仅供学习参考。用户通过本站上传、发布的任何内容的知识产权归属用户或原始著作权人所有。如有侵犯您的版权，请联系我们反馈本站将在三个工作日内改正。

Vue组件设计学习笔记，持续记录

相关推荐

密码登录

账号注册