网站模板设计教程,怎么样做企业模板网站,如何运营微信公众号,深圳精准网络营销推广作者#xff1a;vivo 互联网大数据团队-Wang Lei 本文是vivo互联网大数据团队《BI数据可视化平台建设》系列文章第2篇 -筛选器组件。
本文主要介绍了BI数据可视化平台建设中比较核心的筛选器组件#xff0c; 涉及组件分类、组件库开发等升级实践经验#xff0c;通过分享一些… 作者vivo 互联网大数据团队-Wang Lei 本文是vivo互联网大数据团队《BI数据可视化平台建设》系列文章第2篇 -筛选器组件。
本文主要介绍了BI数据可视化平台建设中比较核心的筛选器组件 涉及组件分类、组件库开发等升级实践经验通过分享一些对交互和业务耦合度高的组件开发迭代的思考希望可以给正在做组件重构解耦的读者带来启发。
往期系列文章BI 数据可视化平台建设1—交叉表组件演变实战
一、引言
BI产品通常包含大量复杂的数据信息需要对其进行快速和准确的处理和分析。筛选器可以帮助BI产品的用户快速地定位所需信息并从海量数据中筛选出有用的数据以便进行深入的分析和决策。敏捷BI作为公司内部用户数最多的可视化平台随着平台的业务增长和版本迭代其筛选器功能也越来越丰富和完善旧的设计架构也显得越来越臃肿且难以维护为了提高筛选器使用的稳定性和降低后续迭代维护成本筛选器的架构升级已经不可避免了本文主要给大家介绍一下筛选器组件的架构升级实践经验。
二、前期设计
2.1 组件选型 前期筛选器组件的职责和交互比较简单主要是对图表数据进行单向的数据过滤并没有应用到其他的业务场景中所以前期的组件设计主要以 业务组件 的思路进行开发实现。
2.2 组件分类
组件类型主要可以分为业务组件和通用组件两种它们在组件的状态管理和界面渲染的设计和实现上是完全不同的。 但无论是业务组件或者通用组件都具备组件本质所包含的三个性质 扩展、通用、健壮 扩展性在原有组件基础上可 二次封装 扩展成新的组件符合设计的开闭原则。 通用性根据组件接受的参数和组件中与业务的解耦比来衡量组件的通用性并不是通用性占比100%的组件就是最好的组件需要根据 不同的场景 分析。 健壮性避免组件中参数处理和函数执行过程可能出现的奔溃和错误导致程序的直接挂断单测以对组件内部 做好边界处理异常错误的捕获来衡量这一标准。
因此两种组件类型没有绝对优劣之分重要的是在保证组件设计的基本原则不变的情况下根据不同的业务场景和需求选择合适的类型 。无论哪种组件随着不断扩展使其通用性提升必然就会降低组件的易用性质而不断丰富一个组件也会导致其组件代码过长、组件使命不单一、不易读、不易维护因此组件设计除了要保证组件的基本性质还要通过明确组件职责、组件拆分粒度以及良好的代码结构和Api设计规范对组件的迭代进行约束避免代码逻辑的过度叠加和膨胀。
2.3 背景痛点
旧版筛选器组件设计存在维护成本高且问题BUG多等问题主要由两个原因造成第一个是业务发展随着业务的快速增长筛选器组件的功能也越来越丰富和完善由原来的单一功能升级成可以支持数据预警、个性化分析等多种业务场景的核心模块第二个是缺乏规范约束主要是缺少良好的代码结构和清晰的组件职责等规范约束导致业务逻辑过度叠加粒度拆分不合理文件多且文件名不规范。最终导致了筛选器组件的稳定性越发不可控。 由于前期设计不合理和缺乏规范约束筛选器组件经过了一段时间的野蛮式迭代扩展带来了以下的痛点问题 重复代码多复用性差相同的业务逻辑需要维护多份代码导致出现bug的概率大大增加后期维护成本增加 业务耦合度高缺乏设计模式进行管理更新迭代过程中处理逻辑需要兼容多种场景代码越来越复杂导致问题难以跟踪难以定位问题意味着你可能需要花大部分的时间处理问题 编码风格不一致维护成本高 项目主要技术栈是Vue但是代码风格有大部分格使用的React的jsx形式进行开发项目存在多人维护个人技术参差不齐导致后续学习成本增加 组件嵌套层级深存在双向数据流不符合Vue 单向数据流状态管理理念无法追踪局部状态的变化增加了出错时 debug 的难度经常出现修改一个模块bug而引起其他模块bug的情况。
三、新版架构设计
3.1 设计思路
旧版的组件随着业务发展迭代已经混杂着大量的业务逻辑组件耦合严重职责也越发不清晰因此为了合理的划分组件职责和清晰代码结构新的架构设计将基于 通用组件 的设计思路将筛选器组件抽离出BI业务从BI项目的架构、技术选型、文档使用等多个方面进行考虑在原来的基础上改造太复杂可行性低所以搭建了一个新的项目将之前所有的筛选器组件迁移到新项目上稳定后替换BI项目上所有旧版筛选器组件后续统一只需维护一个组件库bi-filters。 3.2 实现方案
筛选器组件库bi-filters主要 基于Vue CLI 的 开发/构建目标/库 能力以及 Lerna 包管理工具 进行设计开发这种组件库设计集成了以下特点 按需引入每个UI组件都是一个npm包多语言、工具和样式都是自成体系的npm包可被业务或UI组件灵活引用同时天然支持按需加载。 配置简单如果需要进行构建处理那么每个npm包可单独进行构建配置配置变得更加简单。结合Vue CLI的构件库能力对于简单UI组件的构建几乎可以做到webpack零配置。 独立部署组件库的版本迭代可以更快不需要进行整体构建每个组件可单独快速发布。
1. 利用 Lerna工具进行多包管理快速对组件库进行版本发布 组件库目录结构 2. 组件设计和实现
参考 装饰器设计模式对组件进行抽象设计从而达到业务状态与 UI 状态隔离UI 状态与交互呈现隔离的目的。具体实现是先按功能将组件拆成展示层逻辑层容器层达到组件分层可复用。再通过
$attrs/$listeners对antd组件进行二次封装抽离成在筛选器组件库内的公共组件达到交互可组合。最终使得组件边界清晰符合设计规范中提到的开闭原则、单一职责原则、里氏替换原则。
以文本下拉筛选器组件TextDropDownFilter实现为例 1按功能将组件拆分成 容器层、逻辑层搜索框逻辑层、 下拉列表逻辑层 、展示层搜索框展示层、下拉列表展示层 2BI项目中使用 引入筛选器组件后 在BI应用层处理业务场景将处理业务后的状态信息通过 Vue 插槽(Slots)的方式传递给底层的筛选器组件 。
!-- page.vue一 --
TextDropDownFiltertemplate #addonSearchAfter!-- 业务场景一 -- a-tooltip v-ifxxxBIIcon typeicon-jilian classbtn-jilian v-showxxx/BIIcon/a-tooltip!-- 业务场景二 -- a-tooltip v-ifxxxAIcon typewarning themefilled classbtn-warning/AIcon/a-tooltip/template
/TextDropDownFilter
3搜索框逻辑层接收业务处理后的状态进行不同的UI组合展示
!-- SearchHandler.vue一 --
templatediv classbd-search :class{ active: inputActive }!-- 基础搜索框组件 一 -- Searchv-bind$attrs:searchValuesearchValue:placeholderplaceholdersearchItemhandleSearchItempressEnterhandlePressEnterfocushandleFocusblurhandleBlur/Search!-- 业务层传入的UI 一 -- slot nameaddonSearchAfter/slot/div
/template
4搜索框展示层由 antd 基础组件组成提供交互单一且可复用的UI组件
!-- Search.vue一 --
templateAInputclasscommon-search-input:placeholderplaceholder:valuesearchValueallow-clearchangechangev-on$listenerspressEnter$emit(pressEnter, $event)AIcon slotprefix typesearch //AInput
/template3. 最后利用 Vue CLI 的构建库功能对不同类型的筛选器组件进行单独构建打包
vue cli 的构建库能力可以通过 --target 选项指定不同的构建目标。它允许你将相同的源代码根据不同的用例生成不同的构建。 在组件库项目的 packages 目录下每一个筛选器组件的目录下都需要创建 package.json文件用于组件的构建信息配置
{name: bigdata/TextDropDownFilter, //包名version: 0.0.0, // 版本号private: false, // 为true时不会被发布main: dist/编译文件名.umd.min.js,scripts: {build: vue-cli-service build --target lib --name 编译文件名 --dest dist ./index.js,lint: ,test:unit: },files: [dist],author: ,license: ISC,description:
}
四、效果收益
1. BI项目整体代码量减少组件目录结构清晰只需要专注维护业务逻辑 2. BI业务抽离后筛选器组件可进行独立维护迭代减少代码耦合只需专注功能交互和性能优化提高组件稳定性。 五、总结
从上述的升级过程可以看出组件的抽象与抽象粒度是没有一成不变的统一标准也没有对与错。组件的设计更多的应该去关注如何适配不同的业务场景和需求要求追求更多的是“适合”。有的时候同样的业务场景组件粒度的标准也会随业务场景变化而变化甚至可能随场景增加而持续重构因此为了代码更好的维护和分层以及避免代码逻辑的过度叠加和膨胀必须制定一些组件抽象的规范加以约束。总的来说组件开发的方法论可能是相对中立和普适的但组件库的整体建设方案与所在的行业和业务有很大的关系。不同的行业领域对交互展现的掌控程度是不一样的因此设计组件库方案的时候应该优先从产品项目的集成关系角度出发看待问题这样可以保证业务的拓展和可用性尽可能不被技术方案限制。
