梳理的一点复合组件。可以点击链接-> 在线预览
写这个的时候突然想到了一些东西，也就写在这下面，也算是对以往的回顾。写的比较散比较乱，见谅
好的组件化，对于提效和后期扩展是可具现的一种提升。
- 减少重复的编码、提高效率
- 避免每个地方都去修改，后期维护成本大大降低
组件化是一个项目最基本效益最大的一种方式，但是往往很多实际中的项目都因为各种各样的原因而没有完全推动起来。
项目的组件化只会对当前项目带来效益，那对于公司业务线繁多，项目体量相对较大的时候，就需要定制公司自己的组件库。
根据实际业务场景而定，建设组件库需要开发成本。如果业务线多、系统界面通用性高，且对UI/UE有相应要求，则有必要。
组件是为了提效，不能本末倒置，每一个组件都应该有一定的思考和解决实际业务场景的能力。同时需要保证质量，以及输出相应的文档。
前端虽然本质上还是html，但是承担了更多的业务逻辑相关的工作，因此使得项目越来越大，也变得难以管理。
个人认为前端工程考虑两个方向：
- 项目质量
- 产品质量
关于第一点，代码是写给人看的，如果不考虑项目整体设计和扩展，那么后期必然难以维护，任何人来接手都是非常糟糕的体验。
关于第二点，这个很好理解，产品做出来的基本就是质量有保证，用户能不能用，好不好用。
怎么提升项目质量？
-
清晰项目结构
- 基础的一些目录不必多说，主要是页面的管理。
- 分两种方式，一个是扁平化的目录结构，一个是模块化的目录结构
- 根据实际场景选择
-
基本的代码规范和风格
- eslint为基础，尤其是 husky
- 页面和组件的命名规则
- 避免重复的逻辑代码、行内的css、满篇的any、嵌套的3元运算符、反复套娃的循环和if等等
-
“基础设施”的建设
- 把项目的中一些通用逻辑提成utils方法或者自定义hooks
- 组件化。组件一定要达到UI和业务分离
- 统一的权限处理方案、request和service层的方案（可以视情况而定引入一些自动生成service层的工具，例如pont）
- 一点简单的能同步更新的文档
-
良好的git管理机制
怎么提升产品的质量？
- 熟悉产品业务，这不是只有后端才需要了解的东西
- 了解业务之后，才能真正知道用户用这个产品他最需要的东西是什么，前端应该做到哪种程度
- 产品和UI的经验和专业度不同，前端接收到的信息也不同，因此需要自己熟悉业务，来对这方面进行查漏补缺
- 提高项目质量
- 关注和优化性能问题
- 老生长谈的首页加载问题、体积问题（这种问题一般是在遇到瓶颈、或者接受一个糟糕的项目时需要解决）
- 不要忽略一些体验细节
- http请求都需要loading，除特殊情况除外
- 一定要做防抖
个人认为ts有两个方面的好处，一个是弥补了js弱类型的缺点，另外一个则是强大的提示。
很多同学在写了很久的typescript之后，还是到处在写any。
我从自己的经历看来，只有自己真正感受到typeScript带来的好处之后，才能少些any不写any。
举些例子：
- 使用ts开发的组件或函数，可以直接通过类型提示则知道需要传入什么参数、参数的类型，哪些是必传等等。诈一听似乎没什么感触，但是当参数层级嵌套深，结构复杂的时候ts的优势会指数型的上升。像一些第三方组件库如果文档不够清晰，则直接可通过ts追溯到具体的类型。
- 例如某个详情页拿到了服务端返回的数据，需要显示对应字段。如果不用ts，则需要对照文档挨个的复制，用ts提前定义好类型，则在输入.之后会提示出所有的类型
总之，typescript不仅提高了代码的健壮性、同时极大的提高了代码的可读性和可维护性
有些前端开发者会觉得ts复杂但是用处小，个人认为还是需要一些时间去感受。
但是只要不搞ts体操，是非常通俗易懂的，都是简单的概念操作叠加在一起的。
个人总结的一个最简单的原则：定义什么类型，就传入什么类型；需要什么类型，就传入什么类型。
很多前端开发者都会有一个误区，包括以前的我也有，那就是认为： 前端不需要了解业务，只需要高度还原设计稿就可以。
不知道其他前端开发者有没有过类似的疑惑，“我代码明明可以很严谨，自测也很充分，但是提测之后总是被提不少问题，测试是怎么回事，针对我？”。
我有过这样的疑问，并且来被提的问题拉出来分析了一波，然后再后面的开发中也经过长时间的观察，发现很多问题都来源于对业务不熟悉
- 对业务不熟悉，对代码设计也会出现不合理，提测之后稍微有些改动成本都会增加
- 对业务不熟悉，容易被产品和UI带进坑里，提测之后发现业务逻辑问题
- 对业务不熟悉，在评估方案以及工时的时候也会出现误差，一旦这些出现问题，就会压缩开发时间，导致提测质量低
其实还有一点，对业务不熟悉怎么知道业务的优先级？不知道优先级怎么找产品砍需求？解决不了需求，就解决掉提需求的人。
一个多人开发的项目肯定绕不开分支管理的问题。例如：代码冲突、代码回退、版本依赖等等。
需要一个人人遵守的管理规范，才能避免大部分的问题。
个人感觉比较好的分支管理是：
- master （生产环境分支）
- release （预发环境分支）
- test （测试环境分支）
- dev （开发环境分支）
- feat-* （功能分支）该分支需要保持干净
- 基于master新建，开发完后merge到dev分支，基于dev分支部署到开发环境。
- 自测通过后，merge到test分支，基于test分支部署到测试环境，等待测试验证
- 测试通过后，merge到release分支，基于release分支部署到预发布分支，等待业务验收
- 验收通过后，merge到master分支，正式发布上线。
- fix-* （修复bug分支）
- 流程同上
为了保证feat和fix分支的干净和独立，不能将dev、test、release分支merge到它们身上
总而言之，多人协作开发的时候，一个版本会有多个并行的需求，为了让他们相互独立，需要保证feat分支的干净，修复线上bug则通过hotfix。
最终发布merge到master分支的也只能是feat分支。因为release、test、dev都不干净。
未完待续....
MIT