组件开发方案

npm组件化开发的背景

1. 随着技术的发展，开发的复杂度也愈来愈高，传统开发模式老是存在着==开发效率低，维护成本高==等的弊端。（界面开发太多，风格样式随时均可能调整，若是要调整，可能全部的项目都须要调整，牵一发而动全身）
2. 项目愈来愈多,针对项目进度以及时间要求==每一个人对项目样式的支持度==不是很高，须要一个统一的模式进行管理，提高开发人员的工做效率以及减小bug的产生，让开发人员可以更好地投入到业务开发中,发现组件化开发很是必要

组件化开发的优势、缺点

1. 前端的组件化开发，能够很大程度上==下降系统各个功能的耦合性==，数据相互独立，而且提升了功能内部的聚合性。这对前端工程化及下降代码的维护来讲，是有很大的好处的，内部结构密封，不与全局或其余组件产生影响，特别是针对逻辑复杂的功能可以进行拆分，更好排查问题。（就像电脑零件同样，针对各个零件的问题进行调整）
2. 耦合性的下降，提升了系统的伸展性，下降了开发的复杂度，提高开发效率，下降开发成本。
3. 由于功能已经完善，项目中使用的组件可以让人员更少的接触组件内部通用的逻辑，更加投入到业务的开发，提高你们的开发效率，减小bug的生成，还能让新人员更好、更快的接入公司的开发任务。
4. 目前不少公共组件和项目依赖不少相同的node_modules，若是对组件开发经验不足，中间配合起来，版本不一致可能会致使node_modules出现未知的问题，各个版本针对不一样环境也要作区分。

组件化开发遵循的特性

1.标准性

• 任何一个组件都应该遵照一套标准，可使得不一样区域的开发人员据此标准开发出一套标准统一的组件。

2.专注性

• 设计组件要遵循一个原则：一个组件只专一作一件事，且把这件事作好。

3.拆分性（须要开发人员来把控）

• 一个功能若是能够拆分红多个功能点，那就能够将每一个功能点封装成一个组件，固然也不是组件的颗粒度越小越好，只要将一个组件内的功能和逻辑控制在一个可控的范围内便可，大组件也就是页面又叫作视图，用起来更加方便（没必要通讯），小组件更加灵活（小组件是块砖哪里须要往哪搬）。
• 页面上有一个 Table 列表和一个分页控件，就能够将 Table 封装为一个组件，分页控件 封装成一个组件，最后再把 Table组件 和 分页组件 封装成一个组件。Table 组件还能够再拆分红多个 table-column 组件，及展现逻辑等。

4.可维护性

• 针对之后可能出现的功能要有预见，尽可能作到向下兼容以及新功能的添加可以很好的进行完成开发，尽可能使用一个组件完成功能，实在不行只能分一个新功能组件进行开发完成，若是有不可逆的问题须要调整，还须要严格按照npm版本号标准管理添加版本。

5.可配置性

• 一个组件，要明确它的输入和输出分别是什么。
• 组件除了要展现默认的内容，还须要作一些动态的适配，好比：一个组件内有一段文本，一个图片和一个按钮。那么字体的颜色、图片的规则、按钮的位置、按钮点击事件的处理逻辑等，都是能够作成可配置的。
• 要作可配置性，最基本的方式是经过属性向组件传递配置的值，而在组件初始化的声明周期内，经过读取属性的值作出对应的显示修改。还有一些方法，经过调用组件暴露出来的函数，向函数传递有效的值；修改全局 CSS样式；向组件传递特定事件，并在组件内监听该事件来执行函数等。
• 在作可配置性时，为了让组件更加健壮，保证组件接收到的是有效的属性、函数接收到的是有效的参数，须要作一些校验。

组件拆解

• 组件是相对独立的可复用逻辑单元，多个组件相互做用造成了完整丰富的页面，组件化的思想将前端工程提升到了一个新的高度，其内在表现是将页面进行分割与抽象，达到高复用，易维护的目的，同时，对组件的可靠性，可预测性也提出了要求。总体而言，组件是提升开发效率的利器，下面将探讨一下组件的构成；
  

• 组件能够看作一个简单的I/O模型，组件处于面对用户第一线，具备交互特性，所以能接收与展现相关的数据；组件与组件相互协做，数据流通以对外接口为通道。组件内部主要包含视图、逻辑、样式与状态四个部分，功能的差别也致使不一样组件的具体构成不尽相同，例如纯展现组件只要视图层与属性，容器组件有逻辑、状态、属性，可是没有视图层，这里不区分具体组件的职能，统一讨论全部构成部分；

  1.接口

• 接口对外提供具体功能与扩展，对内传递外部属性，对用户不可见，但承担着桥梁的做用，是各组件组合的粘合剂，所以接口的设计十分重要，可靠的输入输出是组件稳定的基石，功能丰富的接口也将提升组件的使用体验；

  2.交互

• 组件负责与用户的交互工做，提供可操做的功能，同时收集用户输入，而后对数据进行加工，从新给用户呈现新的数据，所以对用户体验提出了高要求，快速响应，界面友好，操做便捷，是优秀组件须要包含的特性，这次组件的开发也将对以上几点作针对性的设计，为了知足快速响应，将组件的执行任务进行优先级的分解，保证组件响应的快速，同时总体对组件进行从新设计，全新的视觉元素与交互规范，势必会提升用户体验与开发效率；

  3.视图

• 视图是用户可视化的界面图形，良好和统一的外观能提升用户的使用体验，经过公司组件化视觉规范来提升组件的视图层表现；

  4.逻辑

• 逻辑是组件功能与外观的基础，对数据状态进行处理，呈现出组件的不一样表现形式，可复用的逻辑将简化组件的结构，同时更加利于维护，这次将公司内部系统常见逻辑进行封装与抽取，实现逻辑层的独立；

  5.样式

• 样式是属于视图层的范畴，单独将样式提取出来，是为了更好的维护，对目前样式进行系统化的整改，将减小平常开发对样式的依赖；

  6.状态/属性

• 状态/属性是一系列I/O和逻辑处理的内在体现，状态/属性的结构设计也决定了组件功能与实现的难易程度，在后续组件设计过程也将具象化状态与属性值；

组件体系

• 根据组件层级与功能划分，造成以下的组件体系：
  
• 底层支撑上层的组件，底层组件提供基本功能，上层组件在此基础上扩展与组合，造成知足特定场景的高聚合组件，组件库的使用人员主要集中在页面和容器级别的组件层级上，从而减小对底层基础组件的依赖；

版本管理

分为三个版本

• 主版本号（A）：当你作了不兼容的 API 修改，0表示处于开发阶段；
• 次版本号（B）：当你作了向下兼容的功能性新增;
• 修订号（C）：当你作了向下兼容的问题修正。

~容许小版本迭代

• 若是有缺省值，缺省部分任意迭代；
• 若是没有缺省值，只容许补丁即修订号（Patch）的迭代

eg.:

• ~1.2.3：>=1.2.3 <1.3.0
• ~1.2：>=1.2.0 < 1.3.0（至关于1.2.x）
• ~1：>=1.0.0 <2.0.0（至关于1.x）
• ~0.2.3：>=0.2.3 <0.3.0
• ~0.2：>=0.2.0 <0.3.0（至关于0.2.x）
• ~0：>=0.0.0 <1.0.0（至关于0.x）

^容许大版本迭代

• 容许从左到右的第一段不为0那一版本位+1迭代（左闭右开）；
  若是有缺省值，且缺省值以前没有不为0的版本位，则容许缺省值的前一位版本+1迭代
  eg.:
• ^1.2.3：>=1.2.3 <2.0.0
• ^0.2.3：>=0.2.3 <0.3.0
• ^0.0.3：>=0.0.3 <0.0.4
• ^1.2.x：>=1.2.0 <2.0.0
• ^0.0.x：>=0.0.0 <0.1.0
• ^0.0：>=0.0.0 <0.1.0
• ^1.x：>=1.0.0 <2.0.0
• ^0.x：>=0.0.0 <1.0.0

锁定（控制）版本

package-lock.json或是yarn.lock。

在npm的版本>=5.1的时候，package-lock.json文件是自动打开的，意味着会自动生成，
package-lock.json（官方文档）能够理解为/node_modules文件夹内容的json映射，并可以感知npm的安装/升级/卸载的操做。能够保证在不一样的环境下安装的包版本保持一致。听上去很不错哈，实际使用中，大部分它的表现确实不错，但是如上述问题：我手动修改了package.json文件内依赖的版本，package-lock.json就没那么聪明（至少目前是，将来会不会变聪明就不可知了），且不会变化。
若是你真的想保证你的包版本在各个环境都是同样的话，请修改下package.json中的依赖，去掉默认前面的^，固然这样的话，你就无法自动享受依赖包小版本的修复了，问题来了，在什么状况下选择哪种呢？

在依赖包严格按照版本规范来开发的，你可使用^来享受包的最新功能和修复。这也是推荐的。
在你不可知或已知依赖包不是那么规范的状况下，或许它在一个小版本（patch）作出不兼容更改（不兼容更改在beta等先行版本中必定[墨菲定律]会发生），那么这个时候，你应该把这个依赖包的版本在package.json上锁住版本，而不该该把它交给package-lock.json来处理
记住一点，绝对不要在生成环境下使用beta等先行版本依赖包，由于若是那是你的私有项目，它会在将来的某一刻坑害了你，若是这是你的共有项目，那么，它必定会在将来的某一刻对你的全部用户作出致命的坑害行为
---

初期开发

实现如图：

1.划分组件

根据组件具体职能不一样，能够划分为以下结构：

• 框架型组件：针对公司项目中组件特定的逻辑功能须要公用的组件能够提取为业务组件，只保证目前各项目框架的公共业务，不掺杂其余的项目的逻辑（fulu商户侧，fl-pro运营侧）
• 功能型组件（Table、Form，目前页面最能体现的组件）：都是提供1个基类，其他进行派生扩展的机制针对实际场景进行开发
• 常规组件（Checkbox、Input、Radio等）：根据定制化样式进行开发

2.提取项目公共页模版

由公共函数类、公共模块类、当前页面组成，全部页面引用公共组件，公共组件继承公共类，开发者不须要写过多公用的代码，开发类由被基类、继承类的公共组件，使用公共组件的的页面三块组成。

• 1.CommonPage：基类，将公共函数（初始化加载、显示隐藏弹框、查询等）与state（页面须要使用的变量）提取公用。
• 2.CommonPageDom：公共组件，继承公共类，能够创建多种组件，自适应各类页面。

• 3.TestPage:引用公共组件，能够经过传入配置文件进行动态加载

  页面划分

• 1.普通页面不带增、删、改
• 2.普通页面带增、删、改、查、弹框
• 3.带tab切换的页面

• 4.其他待扩展的页面
  

3.提取公共函数

不少函数在咱们项目中都会频繁使用，因此须要提取公共出来，方便使用

• 1.验证函数
• 2.数字文字的处理，数组的合并，类型的检验等
• 3.其他可提取的公共函数

4.初期能达到的状况

• 1.UI方面：公共组件样式、交互彻底和公司须要的风格一致
• 2.功能开发：开发者只须要在当前引用组件，传递相应参数就能生成想要的页面

中期开发

一键配置开发

• 1.建立页面1键生成对应页面的组织结构，包括页面文件夹还有models，services，routers等
• 2.经过传递的配置参数给组件，直接生成页面

后期开发

经过拖拉拽直接进行开发

• 1.经过开发的工具直接托拉拽进行生成页面

持续优化

脚手架持续优化

• 1.依赖包的更新，打包的持续优化
• 2.项目使用技术的持续更新

各个流程的优化

• 1.单元测试，自动化测试
• 2.前端自动化部署，动态修改线上代码
• 3.项目性能优化（jsperf、yslow、pagespeed）
• 4.组件功能优化
• 5.公共函数库持续迭代