elementui 前端模板-企业级后端组件构建

组件化,或者说组件分离的目的是共享功能,方便维护。 它能带来的好处是代码编写少,统一管理,统一维护。 一套基础组件代码经过提炼和细化,可以快速支撑业务迭代,提高开发效率。

前言

今年,我们的平台为客户提供了一套企业级的后端组件解决方案。 我们收集了客户的需求,也做了一些监督工作。 因为我们服务于金融机构,所以我们也发现中兴业GFDesign也有同样的想法。 你可以阅读这篇文章。 同时,Ant的AntDesign、Byte的ArcoDesign和SemiDesign、腾讯的TDesign都是类似的企业级设计系统和组件库。 那么说到组件库就不得不说到组件化。

组件化是一种非常优雅的提高效率和保持质量的解决方案,可以帮助开发人员实现功能复用,减少代码重复率,提升开发效率。 帮助设计师快速创建UI设计稿,保证风格的一致性,给用户带来视觉和交互上的一致性,比如颜色、字体、大小等。因此,组件化不仅仅是后端代码的组件化, UI设计稿的组件化,帮助产品总监或UI设计师快速绘制原型和UI设计图。

后端组件建设作为后端基础设施建设的一部分,很大程度上直接决定了后端工程代码的复用率。 组件构建的目的是可重用性和灵活性,进而提供开发效率和质量。 组件化构建可以有效解决很多代码级问题,帮助开发者提高开发质量和效率。

组件规范 设计语言规范

设计语言规范主要用于明确组件的表达形式、偏好或风格elementui 前端模板,例如颜色、布局、字体等。清晰的设计语言规范有两个好处:对内,统一的设计规范将防止各种个性化设计。最大程度的配合业务,保证界面风格的一致性,使页面井然有序; 对外,清晰的设计语言可以帮助企业建立统一的品牌符号和品牌特征,有助于加深产品在用户心中的印象。 统一的色彩和交互方式可以提高用户对产品的熟悉度和信任度。 好的设计语言可以为产品在体验上加分。 设计语言主要包括7个部分。

第一,设计价值观。 设计原则是指导设计师进行设计的指南,它决定了设计语言的基调。 比如国外比较知名的设计语言AntDesign,其核心设计价值观是自然、确定、意义感、成长性。

二、色彩系统。 设计语言需要在一开始就定义整个系统的色调系统。 一旦色调系统建立起来,之前的所有设计都会围绕这个系统进行,包括品牌颜色、辅助颜色、字体黑白灰颜色、不可用颜色、超链接颜色、成功或失败颜色等。看来,设计师会为后续的设计工作维护一套主调色板和辅助调色板; 从开发的角度来看,开发者在实现组件时也会使用变量来存储关键色调值,以便统一维护和替换主题颜色。

第三,图形。 图形是设计语言中不可或缺的一部分。 它还可以将某种概念转化为清晰易读的图形,从而降低用户的理解成本,提高界面的美观度。 比如图标、背景图片、插图等,它们都是图形的一部分。

四、布局。 布局是页面设计中至关重要的一环。 它直接决定了页面内容的区域边界。 只有合理的布局方案才能让页面的内容更加友好。 例如,设计语言AntDesign采用24网格系统,在不同像素的显示设备上以不同的方式呈现。

第五,字体。 字体是系统界面设计中最基本的组成部分之一。 字体系统包括字体类型、字符宽度、线宽、字符粗细和字体颜色。 科学合理的字体系统还可以大大提高用户的阅读体验和效率。

前端模板下载_elementui 前端模板_前端模板框架

第六,阴影。 阴影来自现实生活,由两个不同类别的平面形成,其硬度由它们之间的距离决定。 物体的高度直接影响物体的阴影。 物体距离地面越远,阴影越大,模糊值越高。 通过阴影的合理运用,可以使界面具有层次感,可以将用户的注意力有效地集中在需要突出显示的地方。

第七,图文关系。 图文关系用于定义图片与文字之间的协同关系,保证两者不冲突。 例如,当图片上出现文字时,图片和文字的颜色应该如何搭配,文字应该显示在哪里。

业界知名的设计语言有微软的MaterialDesign、微软的Metro、蚂蚁金服的AntDesign,虽然不同的公司有自己的设计规范。 从零到一构建设计语言是一项繁琐、困难且成本极高的工作,因此我们通常会选择一种成熟的设计语言作为基线语言,并在此基础上进行个性化改造。 比如我们可以根据AntDesign设计规范改变全局色调、字体等来改变自己公司的设计风格。

开发设计规范

根据功能粒度定义组件,可以得到原子组件和分子组件。 虽然这里的原子成分和分子成分是DesignSystem(设计系统)中的理论,但是可以参考相关内容。 明确组件的粒度可以帮助开发人员防止组件的重复开发,最大化组件的功能复用。 除了方便维护之外,还可以提高开发效率。 不能再细分或者不需要再细分的组件称为原子组件。 如果一个组件至少包含一个原子组件,并添加功能代码片段进行功能扩展,则称为分子组件。 作为反例,目前有一个下拉框组件,可以根据传入的配置信息提供下拉选项,并返回选择的对应信息。 如果系统中经常使用某个配置信息的下拉框组件,可以基于下拉框组件进行封装,直接外部化需要从外部导入的配置项,这样就可以得到新的分子成分。

明确了组件的粒度后,需要制定原子组件的开发设计规范,可以分为以下五个部分。

首先,KISS(KeepItSimpleAndStupid)原则。 其核心理念是在保持代码可读性的同时,让代码尽可能简单。 开发者判断一个组件是否符合KISS原则的关键不是代码量的多少,而是代码的可读性。 如果代码的可读性很强,用户可以在短时间内理解它,则说明该组件符合KISS原则。 在大多数情况下,开发人员可以通过遵循代码约定、清晰轻松地命名函数以及添加解释性注释来提高代码可读性。

其次,YAGNI(YouAin'tGonnaNeedIt)原则。 它的核心理念是不要过度设计。 例如,开发人员不应设计当前未使用的功能; 不要编写当前未使用的代码。 代码可以根据业务情况预留扩展点,无需提前实现该功能。

第三,DRY(Don'tRepeatYourself)原则。 其核心思想是增强组件的可重用性。 同一功能的代码逻辑只能实现一次。 开发人员应该将公共部分可视化为工具功能,从而增强代码的可重用性和可维护性。 例如,在大多数情况下,分子组件中的原子组件可以被可视化为公共部分,从而有效提高组件的可重用性。

四、LOD(LawOfDemeter)原理。 它的核心思想是增加组件之间的耦合,并且尽量不依赖它们。 如果需要依赖,则应尽可能依赖具体部分,以保持依赖关系的松散耦合。 如果可以保持松耦合,那么当依赖部分发生变化时,是否可以将影响降到最低。 即使是不兼容的变更,开发人员也可以以最低的成本进行迁移。

第五,SRP(单一责任原则)原则。 其核心思想是一个组件应该只关注一个功能点。 如果违反这个原则,组件内部就会出现大量的逻辑分支,从而导致逻辑混乱,使组件无法扩展和维护。

上述设计原则无需同时遵循,开发者应灵活运用上述设计原则。 例如,在实际业务开发中,如果不确定某个功能是否会被复用,那么为这个暂时不用的复用需求投入大量的时间和精力并不是一个好的做法,这会导致开发量的增加成本。 同时,这也违反了YAGNI原则。 正因如此,开发者在第一次编写代码时不需要花太多的精力去思考可重用性。 如果遇到复用场景,应该遵循DRY原则,构建代码,使其可以复用。

组件化目标基础组件

基础组件就是我们最底层的基础视图组件,它是底层构建的基石,比如我们常用的ElementUI、AntDesign、ViewDesign、Vant等基础组件库。 基础组件可以分为:基础UI组件和基础工具组件。

不同模块或子系统之间的很多业务往往是相连的或相似的。 如果这个时候,我们每个页面都要重复编写业务代码来实现类似的业务场景,那是完全没有必要的。 我们可以将具有类似功能或需求的有机体封装成一个业务组件,并暴露socket以实现灵活的可定制性,以便将它们封装成业务组件。 比如产品模块,ui和交互是一样的,所以抽取出来,把产品信息作为属性传入,根据需求展示产品信息,内部交互自己处理,并且一些交互需要通知父组件。

组件设计原则

对于组件,我们定义了基础组件和业务组件,因为业务组件具有业务属性,属于特定场景,所以这里我们在基础组件的基础上进行一些类型的定义。 当我们区分什么是基本组件时elementui 前端模板,我们可以遵循相应的类型。 做出判断。 这里以 AntDesign 为例:

风格主题

风格主题是指组件的UI风格。 组件在设计规范和技术上支持灵活的样式定制,从而满足企业和品牌多样化的视觉需求,包括但不限于全局样式(主色、圆角、边框)以及指定组件的视觉定制。

样式主题通常使用 CSS 来扩展语言的可变功能。 例如ElementUI的样式采用Sass作为开发语言,并定义了一系列全局/组件样式变量,开发者可以根据自己的需求进行相应调整。 在ElementUI中,我们找到packages/theme-chalk/src/common/var.scss,可以看到样式主题配置变量如下。

elementui 前端模板_前端模板框架_前端模板下载

当开发者需要自定义样式时,可以通过变量覆盖来自定义相关参数值。 此外,ElementUI还提供了在线主题编辑器,可以更改所有全局元素和自定义Element组件的DesignToken,并可以方便地实时预览样式更改后的愿景。 同时,它还可以根据新的自定义样式生成完整的样式文件包以供直接下载。

全球化

国际化是一种能够帮助产品快速适应不同国家和地区要求的设计和制造方法。 它规定开发者应从产品中提取所有与地域语言、国家/地区、文化相关的元素,并能够通过配置等手段快速替换这些元素。 以界面文字为例,不同的国家和地区需要使用不同的语言。

开发组件时,开发人员应该有意识地维护常用词汇,例如交互式反馈(确定、取消等)。 不仅仅是词汇,时间也是国际化中需要注意的部分,比如时区、日期显示等。

组件库应该提供一种在全球范围内设置国际化方案的方法。 例如,ElementUI默认提供locale来实现国际化。 默认是英文,我们导入组件库的时候可以设置。

// 完整引入 Element
import Vue from 'vue'
import ElementUI from 'element-ui'
import locale from 'element-ui/lib/locale/lang/en'

Vue.use(ElementUI, { locale })

其实我们也可以使用vue-i18n插件来提供国际化能力。 国际化方案底层是通过维护多组配置信息来实现的,原理与太原不同。

元件测试

组件是具体的基本公共模块,因此有必要对其进行单元测试。 一方面,单元测试可以覆盖一些端到端测试无法覆盖的点; 另一方面也可以增强组件代码的可维护性,保证代码质量。

推荐使用Jest框架进行组件测试。 它是Facebook开源的后端测试框架。 自带判断库,配置方便。 提供模拟系统、快照测试、异步代码测试、静态分析结果等功能。

在组件测试中,快照测试一般是最常用的。 快照测试会在测试文件目录下生成快照文件目录snapshots/**.test.js.snap。 开发者每次执行测试命令时,Jest都会先执行测试用例,然后将结果与该目录下的快照文件进行比较。 如果两个快照的内容不匹配,则测试用例将不会通过。 生成的快照只有在第一次执行时才会手动更改,后续的自动更新取决于开发者。 开发者需要确认本次生成的快照内容通过,Jest 会将快照更新为当前的执行结果。

在ElementUI中使用Karma+Mocha进行单元测试。 Karma 是一个基于 Node.js 的 JavaScript 测试执行流程管理工具(TestRunner)。 Vue中这个工具的主要功能是在各种主流Web浏览器中运行项目进行测试。 Mocha是一个测试框架,配合vue-cli中的chai判断库实现单元测试。 后续的单元测试说明将作为单独的章节进行描述。

文件管理

组件编译的完成是组件构建的第一步。 只有组件真正运用到业务中,才能在研发和效率提升上取得实质性成果,组件建设才有意义。 组件所使用的文档是否足够清晰、完整是决定组件能否有效使用的关键。 一个优秀的组件文档必须满足以下两个条件。

组件属性的完整描述:文档中应包括组件的属性名称、参数类型、功能说明、默认值、是否需要等。开发者通过阅读组件文档,可以快速了解组件的所有功能,无需花费大量时间花很多时间阅读源代码。 主要使用场景全覆盖:丰富的功能示例可以帮助开发者快速找到对应的使用场景,提高使用组件的积极性和正确性。 ElementUI的演示源代码维护在examples目录中。 当我们在ElementUI项目下运行npmrundev时,它将开始其开发和调试模式,但运行官方文档和演示。

对于开发者来说,我们经常使用Markdown来编译开发文档,社区也有开源的文档生成工具,比如VuePress、dumi等,可以帮助开发者快速生成组件文档。

构建包

组件开发完成后,需要创建包并输出编译后的文件,以便作为第三方依赖被其他模块使用。 一般情况下,开发者会在项目根目录下的build或lib文件夹中输出打包结果,并将该目录添加到.gitignore文件中,以防止打包结果被Git记录然后提交到代码仓库。

前端模板下载_前端模板框架_elementui 前端模板

创建包时需要考虑两件事,一是模块规范,二是组件的实际使用场景。 模块规范包括 CommonJS、AMD、CMD、UMD 和 ES6Module。 组件的使用场景主要有全量导入和按需导入。

完全导入是指将所有组件导入到项目中。 按需加载并不是将所有组件打包为一个整体,而是通过编译的方式单独处理每个文件。

以ElementUI为例,为了实现按需导入,需要使用webpack插件babel-plugin-component并配置.babelrc。

{
  "presets": [["es2015", { "modules"false }]],
  "plugins": [
    [
      "component",
      {
        "libraryName""element-ui",
        "styleLibraryName""theme-chalk"
      }
    ]
  ]
}

把代码放在下面

import { Button } from 'element-ui'

转换成

var button = require('element-ui/lib/button')
require('element-ui/lib/theme-chalk/button.css')

发布规范

当所有组件开发工作完成后,开发者需要使用npmpublish来发布组件的模块。 模块的每次发布还涉及版本号的更新,版本号也应遵循开源社区商定的语义版本控制规范。

语义版本规范是一组版本变更规范,其结构是标准版本格式:XYZ,各个字母的含义如下。

在大多数情况下,版本号从 0.1.0 开始,并随着每个版本的发布而相应更改。 当在即将到来的环境中使用已发布的模块时,它应该已经是 1.0.0 版本。

在即将发布的模块版本发布之前存在其他测试版: