基于自己工作中的体会,还有在做的过程中翻阅的资料,看的资料没有收藏起来,很想指出具体的出处,但是很多都是从各个地方看到的。不过都是在掘金、公众号前端开发、还有知乎上看到的。
😫 前言
随着web业务越来越复杂,一个页面必须要分成多个部分才能使得代码逻辑更加的清晰,出了问题也能更加快速的定位。所以说如果分组件的重要性不言而喻。
一、基本原则
每个组件不能超过300行。网上看好多人都说是200行,但是那样实际操作的话,压力会很大的,导致很多时候会为了分组件而分组件。其实分组件的目的就是为了可读性和可维护性。为了分组件而分组件的话,很多时候写的会很散很乱,违背了分组件的原则。
一切都是为了可读性和可维护性
组件有两种类型:一种是有状态的,一种是无状态的
从不同纬度考虑的话,可以分为四种:逻辑组件(智能组件)、UI组件(木偶组件)、路由组件、状态组件(当前工作环境等常量)
业务代码的复用高于代码的复用
公共组件可以有自己的方法,但是数据的展示依旧是拿props。一定要在跨页面使用的情况下才放在主目录的componets中
无论是Vue、augular还是React提倡的基于数据驱动的设计理念——程序定义好Model和View的关系,剩下的业余处理只需要关心数据变化,View的变化由框架自动执行,无需像jquery时代再去手动操作DOM。
展示组件
容器组件
关注事物的展示
关注事物如何工作
可能包含展示和容器组件,并且一般会有DOM标签和css样式
可能包含展示和容器组件,并且不会有DOM标签和css样式
常常允许通过this.props.children传递
提供数据和行为给容器组件或者展示组件
对第三方没有任何依赖,比如store 或者 flux action
调用flux action 并且提供他们的回调给展示组件
不要指定数据如何加载和变化
作为数据源,通常采用较高阶的组件,而不是自己写,比如React Redux的connect(), Relay的createContainer(), Flux Utils的Container.create()
仅通过属性获取数据和回调
很少有自己的状态,即使有,也是自己的UI状态
除非他们需要的自己的状态,生命周期,或性能优化才会被写为功能组件
二、组件实例(反面例子)
1. 分享组件
**功能:**一个弹框,弹出需要分享的类型、有微信好友、朋友圈、链接微信好友、短信、还有海报生产的路由带参跳转。
变量:按钮的类型、分享出去封面的样式、分享出现带的参数(h5和小程序由于历史原因还是有一些不同的)
文件结果还是很乱的,这是由于本来最外层只有一个index.js,随着开发发现要判断的东西越来越多,所以把他逻辑都拆分了。
- assets: 常量、参数的封装、工具库
- images: 图片库
- renders: 业务组件夹,三种分享类型的不同的封面样式和一个分享标题的组件
- styles: 样式库
- Contianer: 容器组件,把组件的三个部分的组件都包含在外
- ButtonMain
- CoverView
- TitleVIew
- index.js: 逻辑组件,所有逻辑的操作都在这里,参数的封装太多分离到了assets中
- ShareWechat: 封装的原生微信SDK分享
容器组件:
逻辑组件(智能组件):
通过容器组件爆出的props来进行控制容器组件的逻辑。
2. 页面组件
- index: 主页功能
- pages:该房地产功能的其他页面
- componet: 该功能的公共组件
- renders: 主页的业务组件,由于主页内容太多分离出去的
即使分离来页面的各个功能,但是单单是这样引入依旧够多且长的。本来这个是我想要再分离出去。但是一想到要props这么多参数,反而影响来可读性。所以这个组件超过来500行代码。写代码的时候,不管碰到了什么问题,如果影响到了可读性,而自己会一时半会没想到怎么解决,或事件来不及的时候。永远要选择可读性。
三、其他心得
之前我一直认为 代码的重复是罪恶的,是让人唾弃的! 但是看了知乎这篇文章,我发现我好像偏离的轨道,代码的封装是为了代码更容易的去维护。有一种幡然醒悟的感觉。醍醐灌顶一般!
在知乎搜索“前端写代码真的有必要封装太好么?”
觉得很好的两个问题:
- 人的精力是有限的,多考虑大的价值。我现在在面对这么封装,是否应该封装的过程中,耗费的时间确实不少,这样是否是对的呢?肯定不是坏的,但是是否是现阶段最有意义的呢?
- 你现在写的代码,不管公司怎么样,只要你还在写,那么你就要对自己写的代码负责。“你写的项目,你做的项目很有可能在下一个季度交给另外一个人维护,我希望接受代码的人不会在背后骂你”,多想想你未封装的代码会对他人维护带来困扰吗?
暂无评论内容