未登录
登 录
×
<返回上一级
关于前端组件化、状态管理规范化的思考
React.js前端Vuex容器
  • 苏格团队
  • 作者:Tomey

一、开篇

说起前端组件化是这几年老生常谈的话题,笔者就不在这里对前端组件化思想的发展史、优劣做详细的介绍。今天主要与大家分享一下,笔者在开发中从初期的小项目,到后期的项目功能迭代,功能模块越来越多,项目越来越大,组件化规范制定不够完善,多人团队协作开发导致的一些问题,与笔主自己处理的方案的思考。

二、发现、提出问题

1、三张图说明一个业务模块功能迭代图。

第1版

组件单向数据流,父组件状态单向传输子组件

image

第2版

随着功能迭代,非父子组件会共享一些状态。 此处由于非父子组件间状态共享不复杂,优先使用状态提升(状态提升,我们需要把子组件间共享的状态,提升到容器组件进行管理,并有容器组件下发到子组件)解决此类问题。

image

第3版

随着更多的功能迭代,模块分层越来越多,跨多层组件状态共享越来越复杂

image

状态管理redux、vuex就是为了解决此类问题而出现。

image

通过以上的项目模块迭代周期的发现,不可避免的出现多组件状态共享。 通常处理共享状态有三种方式:

  1. 状态提升,我们需要把子组件间共享的状态,提升到容器组件进行管理,并有容器组件下发到子组件。
  2. 状态管理redux、vuex。
  3. 事件机制,子组件改变共享的状态,通过事件管理模块emit分发出去,需要同步更改状态的子组件通过on接收更改事件。

引入状态管理就真的能解决所有的问题吗?

  1. 组件哪些状态需要提取到状态管理?
  2. 如何避免滥用全局状态导致项目混乱?
  3. 容器组件、展示组件如何划分?
  4. 多人协作开发组件规范、风格不统一,组件间共享状态双向修改规则不统一,新人加入学习成本高。

三、解决问题

笔者认为解决问题的方法,就是制定相应规范,保证团队代码风格统一。

  1. 容器组件与展示组件开发规范。
  2. 哪些组件状态应该提取到状态管理,状态管理开发规范。

请看下图:

image

容器型组件:主要是获取、更新、提交、删除内含展示组件状态数据,不包含任何Virtual DOM 的修改或组合,也不会包含组件的样式。

展示型组件:展示型组件主要表现为组件是怎样渲染的,包含了Virtual DOM的修改或组合,也包含组件的样式,同进不依赖任何形式的store。一般可以写成无状态函数,但实际上由于很多展示型组件里依然存在生命周期方法,所以不一定都是无状态的组件。

说明:

  1. 项目初期版本,只有一个容器组件A,容器A包含三个展示组件A1、A2、A3,所有共享状态都有容器A管理。
  2. 随着项目迭代,容器组件A会分裂出两个新模块容器组件B、C。
  3. 容器组件B、C分别包含展示组件B1、B2,C1、C2,且B、C之间存在共享状态。
  4. 容器组件间共享状态数据,统一由状态管理store管理。

规范:

  1. 展示组件必须在容器组件中使用,除了独有的状态,其他共享状态统一由容器组件管理。
  2. 展示组件涉及修改共享状态的操作,例如点击事件,需要把点击事件通过无状态回调函数抛到容器组件,由容器组件统一做状态获取、更新、提交、删除等等操作。
  3. 父子容器组件共享状态,子容器只能读取父容器组件共享状态,不能进行修改(例如子容器不能通过无状态回调函数抛到父容器,由父容器更新状态),保证单向数据流。
  4. 子容器修改父容器或者修改非父子容器共享状态唯一途径,通过状态管理store统一修改。
  5. 由于容器间共享状态不能双向修改,所以状态管理store会保存大量的共享状态数据,需要通过系统模块、容器组件名分层注册需要状态共享的容器组件state。

实例

写了一个vue+vuex的基础实例,可供参考。下载 github

四、结束

文章到此结束,写这篇文章目标主要是记录自己对于组件规范的思考,欢迎各位大佬提出自己的见解,文章有误的地方请大家及时指正~