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

• Z时代
• 2024-01-10
• 分类：综合

  网上看到了好多篇 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变量，外部组件不改变它。

以上是 react/vue 组件设计方法/原则 的全部内容， 来源链接： utcz.com/z/382462.html