最近接手了一个项目,代码写得一般,不过能用,但是项目结构设计就糟透了。因为耦合度太高,封装太过,导致维护性相当差,加两个新接口要同时改10个组件,真是非常痛苦。不过由此,我也对项目结构/组件的设计有了一些新的想法,所以借午休时间记录一下。

1.项目结构与封装

设计具体业务的组件不建议过度封装,而是把视图组件封装好,每个页面设置一个配置项,配置当前页面用到的字段,这样维护起来只需改配置项就可以;

只要你的项目改起来,让人有一种:“这个改完了,卧槽,这里也要改!那里也要改!”的感觉,那么,毫无疑问,项目结构一定是有问题的,因为一个好的项目拆分得一定很好,就是你这里复用的组件就是这里,和它联动的非常少,即使是换接口版本,字段改变也能非常快速地更新;

2.父子组件

尽可能多的让子组件只管渲染,就是说尽量只暴漏渲染用的数据的接口,保持数据的单向流动性,或者说是一个闭环,不是说改动随时存在,在哪里改都可以;

另外,插槽之类的属性(vue中的,其他类似)也要谨慎使用,因为使用插槽的时候,比较不合理的一种使用场景就是,本来传一个完整的对象,一个完整的全量数据,却把某个属性单独暴露出来,改的时候,至少就要改两个组件了,这个我接受不了;

3.组件props

只暴露必要的props,不要全量传进去,在子组件里解构,比如组件只需要一个对象的id值,不要把这个对象整体传进去;

4.接口

保证不同版本接口格式的一致性。比如接口v1:

error_code: 0,
error_msg: "",
data: {
  list: [{ name: 'xxx', age: 16 }],
  count: 1
}

但是第二版变成:

error_code: 0,
error_msg: "",
data: {
  data: [{ name: 'xxx', age: 16 }],
  total_count: 1
}

这样的设计个人感觉非常糟糕,因为虽然是接口升级,其他改动且不管,上面里的改动是毫无意义的,count改为total_count只会让人感觉:“欸?这个分页相关的参数怎么会出问题?”真的非常让人无语。

未完待续,中午刚吃完饭,只想到这些,晚上回去有时间加个例子之类的。。。