业务开发规范

引言：<借用Egg的理念>
“按照一套统一的约定进行应用开发，团队内部采用这种方式可以减少开发人员的学习成本，开发人员不再是『钉子』，可以流动起来。没有约定的团队，沟通成本是非常高的，比如有人会按目录分栈而其他人按目录分功能，开发者认知不一致很容易犯错。”

1.代码目录

1.1 项目代码目录

1.有配置路由的，都应该独立出一个文件夹出来
2.页面文件夹下，放置相应的索引文件index…,组件放在对应的components目录下

src
├── models // 公共数据请求(request) 跟页面映射对应
├── store // 公共store
├── utils // 公共函数库
├── constant // 常量文件
├── map // 映射文件
├── locales // 多语言文件
├── static // 静态资源
├── styles // 全局基础样式
├── components // 公共组件
│	├──ui // 基础ui类
│	├──bussiness // 带业务属性复用类
├── pages //页面代码
│	├──auth // 授权管理
│	│	├──keyManagement // 钥匙管理
│	│	│	├──components
│	│	│	│	├──CardConfig
|	│	│	│	│	├──index.tsx
|	│	│	│	│	├──index.scss
|	│	│	│	│	├──index.tsx
|	│	│	│	│	├──store.ts // 页面性、独立性的组件可以支持
│	│	│	├──List // 列表页面
|	│	│	│	├──index.tsx
|	│	│	│	├──index.scss
|	│	│	│	├──store.ts
│	│	│	│	├──components // 列表页面的组件目录
│	│	│	│	│	├──AddCard // 新增发卡组件
|	│	│	│	│	│	├──index.tsx
|	│	│	│	│	│	├──index.scss
|	│	│	│	│	│	├──SelectorResidents.tsx // 新增发卡-添加租客
|	│	│	│	│	│	├──SelectorTable.tsx // 新增发卡-添加租客-表格组件
│	│	│	│	│	├──ListTable // 列表表格组件
|	│	│	│	│	│	├──index.tsx
|	│	│	│	│	│	├──index.scss
|	│	│	│	│	│	├──index.conf.tsx // 静态资源数据配置
│	│	│	├──Detail // 详情页面
│	│	│	│	├── ...
│	├──device // 设备管理
│	│	├── ...

1.1.1 基础组件

应用特定样式和约定的基础组件 (也就是展示类的、无逻辑的或无状态的组件)

components/ui/
|- FooterButton

1.1.3 页面组件

组件目录下使用index做索引
如果页面代码不长，interface的定义可以放在文件顶部；如果页面代码比较长，可以把相应的配置性信息抽取到index.conf.tsx文件；如果页面中使用到特定的数据也比较长的，也可以单独拎出来，文件末尾以.conf.tsx结尾，比如column.conf.tsx、map.conf.tsx等

|- List/
  |- index.tsx // 作为组件索引，组件第一个进去的找的文件
  |- index.conf.tsx // 提取数据配置： 比如interface的定义的定义等
  |- column.conf.tsx
  |- index.scss
  |- store.tsx // 当前页的数据state
  |- components 

1.1.4 紧密耦合的组件
和父组件紧密耦合的子组件应该放在该组件目录下
如果一个组件只在某个父组件的场景下有意义，这层关系应该放在组件的目录下，不建目录，直接 文件名.tsx

│	├──AddCard
|	│	├──index.tsx
|	│	├──index.scss
|	│	├──selectorResidents.tsx
|	│	├──selectorTable.tsx

1.2.组件命名规则

大写驼峰, 文件命名跟导出的组件名一致

ListTable.tsx
或者
ListTable
 |- index.tsx
 |- index.conf.tsx

--code--
export default ListTable
--------

2. 业务组件边界

2.1 组件原则：

高内聚、低耦合

2.2 高内聚

内聚原则：既能提供相对完整的功能，又不会过于庞大
复用发布等同原则：组件是软件复用和发布的最小粒度软件单元
共同封闭原则：相关的变更都在同一组件中（table组件） --易维护
共同复用原则：将共同复用的内容都放在同一个组件中（）-- 易复用

其实易复用和易维护是相斥的（两个table）

2.3 低耦合

耦合原则：讨论组件之间的耦合关系应该如何设计
无循环依赖原则：A->B->C->A (很多时候是不知不觉形成的)
稳定依赖原则：依赖稳定的组件（基础组件）
稳定抽象原则：一个组件的抽象化程度应该与其稳定性程度一致。（举例子）

2.4 总结

考虑技术问题、业务场景（易变和稳定、依赖和被依赖）

3. zustand 数据视图分离

3.1 作用

传统hooks写法页面头部会定很多的setState,并且触发某个操作之后，会有很多的set操作. 不便于阅读和维护
zustand用于局部state管理，用于数据视图分离

3.2 优势

● 足够简单，足够小
● 快速定位数据源
● 分离的业务逻辑和视图

3.3 store.ts创建原则

页面性、独立性的组件可以支持创建store.ts文件
一个页面允许创建一个store.ts文件
如果页面很简单，使用setState情况较少的，可以直接使用原有情况

3.4 简单API使用