react/vue 组件设计方法/原则

  网上看到了好多篇 react/vue 组件设计方法/原则 ，内容都是雷同（指不该相同而相同）。   我深恶痛绝，并深刻检讨自己，意识到普及互联网知识已经迫在眉睫，绝不容许有人浑水摸鱼。在短暂的失落和悲怆过后，这肩负振兴祖国互联网知识的重任，舍我其谁？   我集百家之长于一身，取其精华去其糟粕，将最精辟的原理和最完善的案例总结在了这里，供大家免费参阅。如有疑问请在下方留言或私信本人，我将第一时间为你解答。

正文：

  作为数据驱动的领导者react/vue等MVVM框架的出现,帮我们减少了工作中大量的冗余代码, 一切皆组件的思想深得人心. 为了让工程师们有更多的时间去考虑业务和产品迭代,我们不得不掌握高质量组件设计的思路和方法.所以笔者将花时间去总结各种业务场景下的组件的设计思路和方法,并用原生框架的语法去实现各种常用组件的开发,希望能让前端新手或者有一定工作经验的朋友能有所收获. 组件库的价值 1） 就个人而言，拥有一套自己的组件库，可以让你的开发变得更高效，让你在行业里更有价值。 2） 就团队而言，拥有一套团队的组件库，可以让协同开发变得更高效规范，让你的团队在公司更具有影响力。 3） 就公司而言，拥有一套公司维护的开源组件库，可以让你的公司在行业里更具有影响力。 哪些情况需要整合一套组件库 1）从业务上看，当业务达到一定规模后，很多地方需要复用 2）从设计上看，产品要遵循一定的设计规范来保持统一性 3）从开发上看，对开发效率要求高，需要快速迭代和响应开发需求 4）从维护上看，需要统一代码管理，需要达到更改一处全局响应的高可维护性 组件设计应遵循什么原则 1） 就近管理 ① 单文件开发 ② 依赖的静态资源放在同级目录 ③ 相关联组件也放在同级目录 2）高复用性 ① 页面级别的复用（基础组件） ② 项目级别的复用- 私有组件库（业务组件） ③ 公司级别的复用- 开源组件库（element-ui、iview） 组件设计思路 按照之前笔者总结的组件设计原则,我们第一步是要确认需求. 一个抽屉(Drawer)组件会有如下需求点: 1>  能控制抽屉是否可见 2>  能手动配置抽屉的关闭按钮 3>  能控制抽屉的打开方向 4>  关闭抽屉时是否销毁里面的子元素(这个问题是5>  工作中频繁遇到的问题) 6>  指定 Drawer 挂载的 HTML 节点, 可以将抽屉挂载在任何元素上 7>  点击蒙层可以控制是否允许关闭抽屉 8>  能控制遮罩层的展示 9>  能自定义抽屉弹出层样式 10> 可以设置抽屉弹出层宽度 11> 能控制弹出层层级 12> 能控制抽屉弹出方向(上下左右) 13> 点击关闭按钮时能提供回调供开发者进行相关操作

需求收集好之后,作为一个有追求的程序员, 会得出如下线框图:

在这里插入图片描述

  对于react选手来说,如果没用typescript,建议大家都用PropTypes, 它是react内置的类型检测工具,我们可以直接在项目中导入. vue有自带的属性检测方式,这里就不一一介绍了.

  通过以上需求分析, 是不是觉得一个抽屉组件要实现这么多功能很复杂呢? 确实有点复杂,但是不要怕,有了上面精确的需求分析,我们只需要一步步按照功能点实现就好了.对于我们常用的table组件, modal组件等其实也需要考虑到很多使用场景和功能点, 比如antd的table组件暴露了几十个属性,如果不好好理清具体的需求, 实现这样的组件是非常麻烦的.接下来我们就来看看具体实现.

react设计原理 单功能原则   使用React的时候，组件或容器的代码在根本上必须只负责一块UI的功能。 我们不要定义一个具有许多功能的组件，这会导致组件的复杂性和难以维护，难以复用。   一个比较合格的组件尽量保证在200行代码内完成。 单一数据源原则   在分析一个组件内部数据的流动时，我们必须明确数据的来源和去向，以及相应的状态 我们不允许一个数据的存在多个来源。就如上面反模式中使用 prop 初始化组件状态一样，我们不允许组件内部的状态来源于props然后又受组件内部setState的控制。 尽量保持： 1）组件单方面接收props的变量，但不改变它； 2）组件内部维护state变量，外部组件不改变它。