CN107832038A - 组件库的实现方法及装置 - Google Patents

Abstract

本发明提供了一种组件库的实现方法及装置，其中，该方法包括：接收前端框系统的业务需求；根据所述业务需求从组件库中获取抽象单文件组件；其中，所述组件库包括多个单文件组件，分别用于实现对应的业务功能。通过本发明，解决了现有技术中前端框架系统过于复杂且维护难度大的问题。

Description

组件库的实现方法及装置

技术领域

本发明涉及数据处理领域，具体而言，涉及一种组件库的实现方法及装置。

背景技术

随着React，Vue等以组件(指令等)为主的优秀前端框架的出现，前端组件化逐渐成为前端开发的迫切需求，当然这一迫切需求也逐渐成为一种主流，一种共识，它不仅提高了前端的开发效率，同时也降低了维护成本。开发者们不需要再面对一堆复杂且难阅读的代码，转而只需要关注以组件方式存在的代码片段。

随着前端技术日新月异的发展，前端组件化开发也经历了很多发展阶段

1.交互少的静态页面时期：公共模块和CSS

这是一个很古老的时代，那时的前端页面就是一些基本的HTML标签以及JS和CSS，页面上大部分都是一些静态的文字。然而，就在这个时期，前端JS和CSS就已经出现了组件化——或者应该理解为模块化，即开发者把不同模块的或者公共的JS和CSS放在不同的文件中，然后在页面引入并使用，这种方式也沿用至今。

2.频繁的早期动态页面时期：动态引入

由于静态页面不能在页面上存储数据，阅读者也不满足于基本的页面交互，更希望页面能够活起来，且能够把交互的数据存储起来，于是出现了很多服务端技术，比如ASP、JSP，这些技术的出现使得前端页面“活”起来了，用户可以根据自己的需求进行数据的交互。

然而，这时的页面上充斥着业务逻辑。随着业务逻辑的增多，页面的内容也越来越多，越来越复杂。在这个时期前端组件化开发得到了一定的发展，开发者已经不满足于简单的将JS和CSS文件模块化，开始把一些公用的页面逻辑独立开来，然后通过页面动态引入的方式进行使用，比如公共的页面头(header)和尾(footer)以及数据库的连接(DatabaseConn.jsp)等。

3.后端为主的MVC时期：Tag标签

由于早期动态页面时期的业务逻辑都写在页面上，随着逻辑的增多，页面越来越复杂，维护起来也越来越难。于是以Servlet为代表的MVC时代逐渐登上历史舞台，这时页面上的逻辑都被转入到servlet中，使得View层的表现更加简洁，也更加的易于阅读，从而达到了开发的分层。

而随着Struts以及Spring的出现，MVC的开发方式达到鼎盛时期，前端View层的展现也变得越来越简单，没有了复杂的业务逻辑，前端的组件化方式主要是taglib标签，比如jsp标签，Struts标签等。把HTML代码和业务逻辑打包成一个标签，然后使用者直接放置在想要的地方，就可以了。但这个时期，整个WEB应用的开发轻前端重后端，那些taglib标签也都是JAVA代码编写的。

4.前端AJAX时期：JS大行其道

由于MVC时期的轻前端重后端的思想，前端页面主要以表格的形式展现，如果想要一些很炫的效果，实现起来就比较复杂了，往往要写一大堆的代码，而且很难阅读。AJAX作为早已经出现的技术在这个时候越来越受到开发者的青睐，于是出现了很多的JS框架，比如JQuery-UI，easy-UI，miniUI以及大名鼎鼎的ExtJS。

这些JS框架的出现使得前端组件化的开发到达了一个新的高度，利用封装Dom、AJAX以及页面交互的方式，一个个的很炫的组件出现了，开发者可以随意的将这些组件应用的页面中，开发变得简单的同时页面也变得越来越好看。由于这些交互都由JS来完成，运行在浏览器端，也大大的减少了服务端的压力，同时也提高了性能。

5.前端MV*时期：自定义组件

随着时间的推移，开发者发现，如果想要修改这些(ExtJS，miniUI)JS框架中的组件是非常困难的，因此开发者希望能够很容易的自定义一些组件。这时以Vue、React为代表的可以自定义组件的JS框架出现了。这些框架的出现不仅可以让开发者自定义组件，而且可以让开发者将已经存在的组件进行封装。

不仅如此，由于有了npm以及bower这些包管理库，开发者可以很容易的将自己开发的组件publish到这些库中，在使用时只要把他们下载下来(比如npm install)就可以直接使用了。

6.CSS组件化：Less和Sass

前面讲了CSS的模块化基本上是将实现某一模块Dom样式的CSS放在不同的文件中，显然随着Web应用的发展，开发者已经很不满足于这种简单的模块化了。其实关于CSS的组件化，业界也早就已经有了很多探索，比如Less，Sass等。那么为什么CSS也要组件化呢？

我们知道CSS是一种扁平的结构，一个Dom可能对应着一个CSS样式，而这些CSS样式很有可能出现公共的部分，那么提取这些公共的部分也就实现了CSS的组件化，在诸如less和sass出现之前，开发者都是把公共的CSS样式写成一个个公共class，但是这样之后CSS文件的阅读性就变得困难了，当然也不容易修改。而less和sass出现之后，使得CSS的编程可以定义变量，可以实现继承，CSS内容的结构也变得更加清晰，提高了CSS文件的阅读性，更容易让人理解，修改起来也变得简单。

在大型软件系统中，Web应用的前后端已经实现了分离，而随着REST软件框架的发展，后端服务逐步倾向于微服务，简单来说就是将一个大型后端服务，拆分成多个小服务，它们分别部署，降低了开发的复杂性，而且提高了系统的可伸缩性。而前端方面，随着技术的发展，开发的复杂度也越来越高，传统开发模式总是存在着开发效率低，维护成本高等弊端。

传统开发方式效率低以及维护成本高的主要原因在于，很多情况下我们是将一个系统做成了整块应用，而随着业务的增长或者变更，系统的复杂度往往会呈现指数级的增长，出现的情况就是，一个小小的改动或者一个小功能的增加可能会引起整个逻辑的修改，造成牵一发而动全身。

针对现有技术中存在的上述问题，目前尚未发现有效的解决方案。

发明内容

本发明实施例提供了一种组件库的实现方法及装置，以至少解决现有技术中前端框架系统过于复杂且维护难度大的问题。

根据本发明的一个实施例，提供了一种组件库的实现方法，包括：接收前端框系统的业务需求；根据所述业务需求从组件库中获取抽象单文件组件；其中，所述组件库包括多个单文件组件，分别用于实现对应的业务功能。

可选的，所述组件库包括以下类别的组件：表单组件，视图组件，基础组件，导航组件，定制主题，指定类型。

可选的，所述表单组件包括以下子组件：级联选择、输入框、数字输入框、单选框、复选框、开关、滑动块、文件上传、日期选择、时间选择、穿梭框；和/或，

所述视图组件包括以下子组件：告警、全局提示、通知提醒、对话框、文字提示、气泡提示、进度条、时间轴、卡片、标签、折叠面板；和/或，

所述基础组件包括以下子组件：按钮；和/或，

所述导航组件包括以下子组件：面包屑、导航菜单、加载进度条、分页、步骤条、标签页、树形控件；和/或，

所述指定类型包括以下子组件：图钉、返回顶部、加载中。

可选的，所述多个单文件组件通过元素属性进行分类，其中，所述元素属性包括以下至少之一：字体、颜色、大小、线宽、形状、空间。

可选的，每个所述单文件组件与其他至少一个元素之间存在可视化的对应关系。

可选的，所述多个单文件组件之间根据关联性进行归组。

根据本发明的另一个实施例，提供了一种组件库的实现装置，包括：接收模块，用于接收前端框系统的业务需求；获取模块，用于根据所述业务需求从组件库中获取抽象单文件组件；其中，所述组件库包括多个单文件组件，分别用于实现对应的业务功能。

可选的，所述组件库包括以下类别的组件：表单组件，视图组件，基础组件，导航组件，定制主题，指定类型。

可选的，所述多个单文件组件通过元素属性进行分类，其中，所述元素属性包括以下至少之一：字体、颜色、大小、线宽、形状、空间。

可选的，每个所述单文件组件与其他至少一个元素之间存在可视化的对应关系。

根据本发明的又一个实施例，还提供了一种存储介质。该存储介质设置为存储用于执行以下步骤的程序代码：

接收前端框系统的业务需求；

根据所述业务需求从组件库中获取抽象单文件组件；

其中，所述组件库包括多个单文件组件，分别用于实现对应的业务功能。

通过本发明，通过职责单一的组件来搭建整个前端框系统，通过组件快速完成需求，可以解决现有技术中前端框架系统过于复杂且维护难度大的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的组件库的实现方法的流程图；

图2是根据本发明实施例的组件库的实现装置的结构框图；

图3是本发明实施例的组件构架图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

实施例1

在本实施例中提供了一种组件库的实现方法，图1是根据本发明实施例的组件库的实现方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，接收前端框系统的业务需求；

步骤S104，根据业务需求从组件库中获取抽象单文件组件；

其中，组件库包括多个单文件组件，分别用于实现对应的业务功能。

通过上述步骤，通过职责单一的组件来搭建整个前端框系统，通过组件快速完成需求，可以解决现有技术中前端框架系统过于复杂且维护难度大的问题。

可选地，上述步骤的执行主体可以为数据库，应用于PC端的页面产品等，但不限于此。

可选地，组件库包括以下类别的组件：

表单组件，视图组件，基础组件，导航组件，定制主题，指定类型。

可选的，表单组件包括以下子组件：级联选择、输入框、数字输入框、单选框、复选框、开关、滑动块、文件上传、日期选择、时间选择、穿梭框；

视图组件包括以下子组件：告警、全局提示、通知提醒、对话框、文字提示、气泡提示、进度条、时间轴、卡片、标签、折叠面板；

基础组件包括以下子组件：按钮；

导航组件包括以下子组件：面包屑、导航菜单、加载进度条、分页、步骤条、标签页、树形控件；

指定类型包括以下子组件：图钉、返回顶部、加载中。

可选的，多个单文件组件通过元素属性进行分类，其中，元素属性包括以下至少之一：字体、颜色、大小、线宽、形状、空间。

可选的，每个单文件组件与其他至少一个元素之间存在可视化的对应关系。

可选的，多个单文件组件之间根据关联性进行归组。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。

实施例2

在本实施例中还提供了一种组件库的实现装置，用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图2是根据本发明实施例的组件库的实现装置的结构框图，如图2所示，该装置包括：

接收模块20，用于接收前端框系统的业务需求；

获取模块22，用于根据所述业务需求从组件库中获取抽象单文件组件；其中，所述组件库包括多个单文件组件，分别用于实现对应的业务功能。

可选的，所述组件库包括以下类别的组件：表单组件，视图组件，基础组件，导航组件，定制主题，指定类型。

可选的，所述多个单文件组件通过元素属性进行分类，其中，所述元素属性包括以下至少之一：字体、颜色、大小、线宽、形状、空间。

可选的，每个所述单文件组件与其他至少一个元素之间存在可视化的对应关系。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

实施例3

本实施例用于结合实例对本申请进行详细说明，可以补充和解释以上实施例的方案。

本实施例属于web前端组件化技术领域，可应用于PC端的网页开发领域。

本实施例提出一个大且复杂的场景能够被分解成几个小的部分，这些小的部分彼此之间互不干扰，可以单独开发，单独维护，而且他们之间可以随意的进行组合。这种化繁为简的思想在后端开发中的体现是微服务，而在前端开发中的体现就是组件化。

组件化的工作方式信奉独立、完整、自由组合。目标就是尽可能把设计与开发中的元素独立化，使它具备完整的局部功能，通过自由组合来构成整个产品。

Web前端组件化库就是根据航旅纵横实际业务应用开发过程中的经验和总结，提炼、开发出的一套功能逻辑覆盖广泛，交互方式统一，视觉风格一致的常用的页面组件库，一个整体的页面项目可以由无数个其中独立的组件快速高效的搭建起来，提供了工作效率，解放了大量重复的劳动力。

umeUI(本实施例的组件库)是一套基于Vue2.0的UI组件库，主要应用于PC端的页面产品，包括如下：

umeUI的设计原则

对比(Contrast)

对比的基本思想是，要避免页面上的元素太过相似。如果元素(字体、颜色、大小、线宽、形状、空间等)不相同，那就干脆让它们截然不同。要让页面引人注意，对比通常是最重要的一个因素，正是它能使读者首先看这个页面。

重复(Repetition)

让设计中的视觉要素在整个作品中重复出现。可以重复颜色、形状、材质、空间关系、线宽、字体、大小和图片，等等。这样一来，既能增加条理性，还可以加强统一性。

对齐(Alignment)

任何东西都不能在页面上随意安放。每个元素都应当与页面上的另一个元素有某种视觉联系。这样能建立一种清晰、精巧而且清爽的外观。

亲密性(Proximity)

彼此相关的项应当靠近，归组在一起。如果多个项相互之间存在很近的亲密性，它们就会成为一个视觉单元，而不是多个孤立的元素。这有助于组织信息，减少混乱，为读者提供清晰的结构。

umeUI具有以下特性

高质量，功能较为丰富

完善的API文档，使用灵活

风格统一，交互友好的UI

可自由定制主题

umeUI根据功能划分为6个类别，分别为表单组件类，视图组件类，基础组件类，导航组件类，定制主题，其他类型，含有34个小类，每个小类都是一种组件的提炼，包含多种需求的实现，用户可以根根据自己的需求进行配置，图3是本发明实施例的组件构架图。

父子组件的通信实现，父组件与子组件的通信方式包括广播(broadcast)和分发(dispatch)两种，由于vue2.0已将这两种方式删除，所以必须进行自定义实现，

广播的实现：

分发的实现：

本发明实施例的方案，存在如下有益效果：

降低整个系统的耦合度，在保持接口不变的情况下，我们可以替换不同的组件快速完成需求，例如输入框，可以替换为日历、时间、范围等组件作具体的实现。

基于Vue 2.0，开发更加快速，umeUI基于Vue2.0开发，Vue2.0是当下最快的前端框架之一，小巧，API友好，可用于开发的复杂单页应用。

性能提升，业务逻辑之间通信由传统的事件驱动转为数据驱动，页面元素的更新和渲染更加实时和快速。

自定义主题文件，更易扩展，umeUI使用less文件，所有的颜色都有一个变量维护，通过编写less文件完成自定义主题，另外组件内部也提供一些修改效果的参数。

调试方便，由于整个系统是通过组件组合起来的，在出现问题的时候，可以用排除法直接移除组件，或者根据报错的组件快速定位问题，之所以能够快速定位，是因为每个组件之间低耦合，职责单一，所以逻辑会比分析整个系统要简单。

提高可维护性，由于每个组件的职责单一，并且组件在系统中是被复用的，所以对代码进行优化可获得系统的整体升级。例如某个组件负责处理异步请求，与业务无关，我们添加缓存机制，序列化兼容，编码修正等功能，一来整个系统中的每个使用到这个组件的模块都会受惠；二来可以使这个组件更具健壮性。

实施例4

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：

S1，接收前端框系统的业务需求；

S2，根据业务需求从组件库中获取抽象单文件组件；

其中，组件库包括多个单文件组件，分别用于实现对应的业务功能。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行接收前端框系统的业务需求；

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行根据业务需求从组件库中获取抽象单文件组件；其中，组件库包括多个单文件组件，分别用于实现对应的业务功能；

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种组件库的实现方法，其特征在于，包括：

接收前端框系统的业务需求；

根据所述业务需求从组件库中获取抽象单文件组件；

其中，所述组件库包括多个单文件组件，分别用于实现对应的业务功能。

2.根据权利要求1所述的方法，其特征在于，所述组件库包括以下类别的组件：

表单组件，视图组件，基础组件，导航组件，定制主题，指定类型。

3.根据权利要求2所述的方法，其特征在于，

所述表单组件包括以下子组件：级联选择、输入框、数字输入框、单选框、复选框、开关、滑动块、文件上传、日期选择、时间选择、穿梭框；和/或，

所述视图组件包括以下子组件：告警、全局提示、通知提醒、对话框、文字提示、气泡提示、进度条、时间轴、卡片、标签、折叠面板；和/或，

所述基础组件包括以下子组件：按钮；和/或，

所述导航组件包括以下子组件：面包屑、导航菜单、加载进度条、分页、步骤条、标签页、树形控件；和/或，

所述指定类型包括以下子组件：图钉、返回顶部、加载中。

4.根据权利要求1所述的方法，其特征在于，

所述多个单文件组件通过元素属性进行分类，其中，所述元素属性包括以下至少之一：字体、颜色、大小、线宽、形状、空间。

5.根据权利要求1所述的方法，其特征在于，每个所述单文件组件与其他至少一个元素之间存在可视化的对应关系。

6.根据权利要求1所述的方法，其特征在于，所述多个单文件组件之间根据关联性进行归组。

7.一种组件库的实现装置，其特征在于，包括：

接收模块，用于接收前端框系统的业务需求；

获取模块，用于根据所述业务需求从组件库中获取抽象单文件组件；

其中，所述组件库包括多个单文件组件，分别用于实现对应的业务功能。

8.根据权利要求7所述的装置，其特征在于，所述组件库包括以下类别的组件：

表单组件，视图组件，基础组件，导航组件，定制主题，指定类型。

9.根据权利要求7所述的装置，其特征在于，

所述多个单文件组件通过元素属性进行分类，其中，所述元素属性包括以下至少之一：字体、颜色、大小、线宽、形状、空间。

10.根据权利要求7所述的装置，其特征在于，每个所述单文件组件与其他至少一个元素之间存在可视化的对应关系。