第2期:React中如何分组件

基于自己工作中的体会,还有在做的过程中翻阅的资料,看的资料没有收藏起来,很想指出具体的出处,但是很多都是从各个地方看到的。不过都是在掘金、公众号前端开发、还有知乎上看到的。

😫 前言

随着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行代码。写代码的时候,不管碰到了什么问题,如果影响到了可读性,而自己会一时半会没想到怎么解决,或事件来不及的时候。永远要选择可读性。

三、其他心得

之前我一直认为 代码的重复是罪恶的,是让人唾弃的! 但是看了知乎这篇文章,我发现我好像偏离的轨道,代码的封装是为了代码更容易的去维护。有一种幡然醒悟的感觉。醍醐灌顶一般!

在知乎搜索“前端写代码真的有必要封装太好么?”

觉得很好的两个问题:

  • 人的精力是有限的,多考虑大的价值。我现在在面对这么封装,是否应该封装的过程中,耗费的时间确实不少,这样是否是对的呢?肯定不是坏的,但是是否是现阶段最有意义的呢?
  • 你现在写的代码,不管公司怎么样,只要你还在写,那么你就要对自己写的代码负责。“你写的项目,你做的项目很有可能在下一个季度交给另外一个人维护,我希望接受代码的人不会在背后骂你”,多想想你未封装的代码会对他人维护带来困扰吗?
© 版权声明
THE END
喜欢就支持一下吧
点赞9 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容