大宗商品价格查询网站,我的世界充钱网站怎么做,wordpress seo选项,广西网站建设电话前言
这天突然收到了 UI 修改设计稿的消息通知#xff1a;“xxx 已修改 xxx 项目并 了你#xff0c;请及时查看变更内容”#xff0c;一条、两条、三条 …#xff0c;修改消息铺天盖地而来#xff0c;然后就什么都看不到了#xff08;因为我选择开启消息免打扰#xf…
前言
这天突然收到了 UI 修改设计稿的消息通知“xxx 已修改 xxx 项目并 了你请及时查看变更内容”一条、两条、三条 …修改消息铺天盖地而来然后就什么都看不到了因为我选择开启消息免打扰但没多久产品就非常贴心的询问是否已经收到了对应的消息自然免不了还要介绍一下本次修改的内容和原因消息免打扰失效。
于是我心甘情愿的打开了设计稿正打算好好欣赏欣赏不曾想一道光芒一闪而过是谁拉开了窗帘看到了这样的内容 而这个显示方式之前使用的是 Steps 步骤条 的方式展示的类似于
意味着要从一个 Steps 步骤条 改变成一个 progress-step 流程节点 的形式这很难实现吗不难很容易实现吗倒也未必 【扩展】假设现在有个面试官就用这个 progress-step 组件作为场景题想想你该如何描述对这个组件的设计思路
组件设计基本原则
撸起袖子一把梭
千万先别急着撸起袖子开干咱们先来聊聊组件设计的基本原则往往一把梭哈的代码容易形成一个糅杂着各种逻辑的组件因为这样的设计是脆弱的很容易带来副作用和难以预知的结果需求不变更还好需求要是频繁变更那么主要问题就会出现可能因为一个原因去改变组件就会破坏其他的职责行为于是你不得不在多处都进行修改。
怎么知道一个组件复不复杂这就要看组件内部到底维护了多少和自身状态相关的数据即非 props 传入的数据对于现在的 Vue / React 而言都是可以通过 数据来驱动视图 的用一个函数式表示即 UI render(data) 或 UI f(data)这意味着一个组件至少需要做到 数据data 和 视图UI 的解耦。
单一职责
单一职责原则SRP - single responsibility principle 中的 职责 是什么你可以理解为是组件的 行为这个行为可以是渲染一个列表、展示一张图片、发起一个请求等等当组件的这个行为发生修改意味着这个组件本身发生了变化此时该组件就是 单一职责 的。
为什么不能多职责
大部分人经常会选择忽视一个组件的多个职责带来的缺陷这里举个常见查询页面的例子
一部分是和查询条件相关的表单部分 负责和用户进行各种交互比如表单联动、表单重置、表单折叠等等同时它需要收集、提供用户已经填入的数据 一部分是展示查询结果的表格部分 将接口响应的数据展示在表格中同时也要支持与用户的各种交互比如切换页码、页大小、上一页、下一页、跳转页等 一部分是负责将表单数据发送给服务器进行数据交互即发起请求
假设此时按照 撸起袖子一把梭 的原则去编写这个组件页面一定会将表单交互、表格交互、发起请求、处理响应等逻辑混在一个组件页面当中
表单的交互逻辑需要维护行为 1表格的交互逻辑需要维护行为 2请求的发起和响应的处理也需要维护行为 3
假设现在接口响应的数据结构发生了变化在当前的组件页面中你可能需要重新修改处理判断不同响应状态码下页面的表现同时还得修改表格的展示方式又或者需要根据响应的数据内容自动填充表单但由于数据结构的变化还得去调整表单相关的部分此时仅仅一个数据结构改变的原因就可能影响了三个部分的内容因为它们耦合了。
多职责的缺陷
组件内容相互耦合当需求变更时存在相互破坏的可能组件内容各个部分的逻辑杂糅不易于阅读和维护经过不断的迭代会使得单个组件代码量不断增大
让组件具有单一职责
关于这一点你完全可以从你平时在项目中使用到的 UI 组件库中去看看比如 Element UI 中表单相关的组件就分为
Form 组件负责整体表单的展示形式和对整体数据的处理FormItem 组件单个具体的表单组件的展示形式和单个表单的数据处理Input、Select、Option 等等具体的表单组件
基于此还是将上述的例子改变成单一职责
表单部分需要单独封装成组件主要提供表单展示形式、交互能力、数据处理能力表格部分需要单独封装成组件主要负责提供对数据展示、交互的能力查询页面组件负责提供发起请求数据和处理数据响应的能力并将表单组件和表格组件组合在一起
这样一来即便后续响应的数据结构发生改变也不需要再去修改表单和表格部分的内容而是在当前的查询页面组件中处理好对应的数据格式即可比如将接收到的数据处理成符合表格或表格组件需要的格式即可。
单一职责的优点
单个组件的内容独立分离需求变更时只需要修改对应组件单个组件逻辑只存在于该组件中保证组件代码的简洁性、易读性和维护性在不断迭代中只需要修改对应组件的内容不会导致页面中的其他组件代码量增大
通用性
组件的核心是需要体现在业务中的在项目中的大多数组件都属于业务组件不具备通用性因为具有通用性的组件不应该只满足于某个业务因此组件的设计要考虑从业务中抽离。
设计通用性组件应该考虑什么
数据data 和 视图UI 的解耦 见过不少人封装组件就真的只是将原页面内容单纯的剪切出去视图部分大多是硬编码除此之外组件维护了七七八八的状态巴不得这个组件在外部使用的时候什么都不用传递这样的组件显然不具备通用性因此一定要将数据和视图进行解耦 保证组件的 单一职责行为 复用一个组件时是为了重复使用其职责行为而只有单一职责的组件才能够被更好的复用多个单一职责的组件就能更好的实现 组合性如果一个组件错误地拥有多个职责时就会增加复用时的开销 组件只提供 最基础的 DOM 和 交互逻辑 不要让一个组件将视图相关的 DOM 完全掌控在内部应该将容易变化的部分交给使用者自己去定义如利用插槽比如 Element UI 中的 Table 组件就提供了 render-headerTable-column Attributes、headerTable-column Scoped Slot、appendTable Slot 用于自定义渲染 组件封装应该 隐藏内部细节和实现意义通过 props 控制具体行为和输出 保证组件的纯度减少组件的副作用比如不要在组件中直接使用一些全局变量等因为这不符合封装的特性还容易带来不可预测的行为 组件封装保证 可测试性 组件的可测试性也决定着组件封装的通用性如果在为一个组件编写测试用例时需要非常复杂那么大致是组件设计存在问题
设计 progress-step 组件 接下来就该看看到底该如何分析和设计这个 progress-step 组件了上面我们提到了最基本的要做到 数据data 和 视图UI 的解耦那实际上也就意味着要从这两个大的方向去考虑。
视图UI
确定视图展示方式
拿到视图肯定要进行分析UI 图展示的不一定全面因此必须要确定所有可能的展示方式在和产品沟通的过程中确认了这个视图的三种展示形态 串行展示类似于 并行展示类似于 混合展示类似于
但你仔细查看 UI 稿的设计其实完全可以将它归类为第二种展示方式否则你还得为这个 UI 图单独实现另一种展示方式并且在和产品的沟通中也得到了同意。
确定实现方式
首先肯定得去看看社区中是否有类似的方案可以直接使用或者经过小的改动可以被使用的奈何业务就是业务果然没找到合适的但在查找方案的时候也了解到了几种实现方案
基于普通 DOM 元素实现基于 SVG 实现基于 Canvas 实现
最后两种方案我看到的大多是需要支持各种可比较复杂的拖拽、复制、连接的方式并且其具体实现也是比较复杂如果其其不是很熟悉的话无论在实现还是在后续的各种调整上会花费大量时间而且如上的一个需求无非是一些展示和简单的交互并不需要涉及如此复杂的各种自定义操作。
再举个例子比如前面提到的 Steps 步骤条 也是基于普通 DOM 元素实现的并且也确实没有太多需要用户自定义的操作。因此可以将 progress-step 组件当做 Steps 步骤条 的升级版另外考虑开发时间的限制选择方案一是最合适的。
确定实现细节
上述展示方式虽然有三种但实现时可以先实现最简单的 串行展示 方式 而 并行展示 其实相当于三条串行展示的合并分别是上边、中间、下边的串行方式最后的 混合展示 其实只要你实现了前面两种方式这种方式无非是相当于组件的递归渲染只不过位置上需要做一些处理
串行展示 单节点的 虚线 和 箭头 可以借助元素的伪元素 ::before、::after 并通过定位实现 并行展示 上下边的部分仍然可以看做是串行节点的展示中间的部分可以通过一个元素来实现边框效果并且可以认为是前后节点与这个边框的串行版本 混合展示 实现了前面两种模式混合展示方式其实就只是根据数据来进行组件递归渲染
数据data
作为前端肯定要具备看到 UI 就能大致设想出其对应 data 的基本结构而且上述经过视图分析之后已经得到其对应的三种具体展示形式在真正开始写代码前请先把需要封装的组件涉及的核心数据结构给设计好毕竟这个数据最终是需要从外部传入的 串行展示 多个节点意味着整体应该设计为一个数组单个节点即对应数组的每一项元素信息 data [{status: completed , name: 完成 }, {status: processing , name: 当前处理节点 }, {status: pending , name: 待处理 }
]并行展示 可以看做是上下两个串行展示的合并可将数据带有并行的节点也使用数组来表示 data [{status: completed , name: 开始 }, [ // 1. 这个数组表示是并行节点[ // 1.1 这个数组表示是并行节点中上边 串行节点的数据{status: completed , name: 完成 }, {status: processing , name: 当前处理节点 }, {status: pending , name: 待处理 }],[ // 1.2 这个数组表示是并行节点中下边 串行节点的数据{status: completed , name: 完成 }, {status: processing , name: 当前处理节点 }, {status: pending , name: 待处理 }]],{status: pending , name: 结束 },
]混合展示 相当于并行节点中又包含并行节点类似于 data [{status: completed , name: 开始 }, [ // 1. 这个数组表示是并行节点[ // 1.1 这个数组表示是并行节点中上边 串行节点的数据{status: completed , name: 完成 }, [// 1.1 这个数组表示是并行节点中的并行节点[// 1.1.1 这个数组表示是并行节点中上边 串行节点的数据{status: processing , name: 当前处理节点 }], [// 1.1.2 这个数组表示是并行节点中下边 串行节点的数据{status: processing , name: 当前处理节点 }], ],{status: pending , name: 待处理 }],[ // 1.2 这个数组表示是并行节点中下边 串行节点的数据{status: completed , name: 完成 }, {status: processing , name: 当前处理节点 }, {status: pending , name: 待处理 }]],{status: pending , name: 结束 },
]实现 progress-step 组件
其大部分的实现思路已经在上面介绍过了这里就不再额外介绍一些样式计算相关的内容下面直接展示效果和源码。
props 简介
data要展示的节点数据colors不同节点状态的颜色status不同节点状态的值size节点图标的大小stepWidth节点占据的宽度space节点之间的间距
const props withDefaults(definePropsPropsType(), {data: () [],colors: () [#d2d2d2, #3a84fb, #67d36f],status: () [pending, processing, completed],size: 25,stepWidth: 80,space: 20,
});效果展示
串行展示
const data [{ status: completed, title: 开始, description: 这是描述 },{ status: processing, title: 处理中, description: 这是描述 },{ status: pending, title: 待处理, description: 这是描述 },{ status: pending, title: 结束, description: 这是描述 },
]并行展示
const data [{ status: completed, title: 开始, description: 这是描述 },[[{ status: completed, title: 已完成, description: 这是描述 },{ status: completed, title: 已完成, description: 这是描述 },{ status: pending, title: 待处理, description: 这是描述 },],[{ status: completed, title: 已完成, description: 这是描述 },{ status: pending, title: 待处理, description: 这是描述 },],],{ status: pending, title: 结束, description: 这是描述 },
]混合展示
const data [{ status: completed, title: 开始, description: 这是描述 },[[{ status: completed, title: 已完成, description: 这是描述 },{ status: completed, title: 已完成, description: 这是描述 },[[{ status: completed, title: 已完成, description: 这是描述 },{ status: pending, title: 待处理, description: 这是描述 },],[{ status: completed, title: 已完成, description: 这是描述 },{ status: processing, title: 处理中, description: 这是描述 },]],{ status: pending, title: 待处理, description: 这是描述 },],[{ status: completed, title: 已完成, description: 这是描述 },{ status: completed, title: 已完成, description: 这是描述 },[[{ status: completed, title: 已完成, description: 这是描述 },{ status: pending, title: 待处理, description: 这是描述 },],[{ status: completed, title: 已完成, description: 这是描述 },{ status: processing, title: 处理中, description: 这是描述 },]],{ status: pending, title: 待处理, description: 这是描述 },],],{ status: pending, title: 结束, description: 这是描述 },
]不足
现存缺点比较明显
当流程节点超过视图容器很难动态调整好各个节点间的距离现在暂时使用滚动条代替不能无限制渲染节点层数最大层数为 3 如混合模式所示动态计算方式仍存在缺陷节点内容变化导致高度、位置的计算问题…
源代码
需要查看代码的可通过此处查阅源代码
代码目录 最后
在实际实现过程中涉及到动态计算的部分很容易理不清包括动态计算矩形框高度、宽度以及节点位置等以上仅仅算是一个实现思路不要害怕写出不完美的代码期望各位小伙伴能够在评论区给出更优质的方案
