data 归类

data用于管理视图驱动相关数据，也会存放一些非视图相关数据，是一个页面/组件中数据最集中也最容易混乱的地方。可以按如下规则进行梳理：

大部分数据，尤其是需要进行视图驱动且是对象类型时，不要直接定义在data的根下，而是包装一层不会变动的object，以此保持vue的追踪，比如

//x
data(){
  name:'xx'
}
//要
data(){
  viewData:{
    name:'xx'
  }
}

也只有这样才能使用Vue.set/$set接口进行新属性的扩展。（Vue2）

大部分的页面/组件都会涉及一些类似的数据范围，可以归类为

data(){
  //初始化一次后不会变化的数据
  finals:{
    name:null
  },
  //常量
  consts:{
    MAX:10
  },
  //不同区域的加载状态
  loadings:{
    table:false
  },
  //也可以按照使用方式/业务区分
  selected:{
    //管理视图中选中的数据
  },
  tree:{
    //管理视图中所有tree相关数据
  }
}

无论是按照数据类型分还是按照用途分，尽量不要直接将数据定义在data的根下。

组件层次

所有基于组件开发的视图框架都存在组件封装度的问题 —— 一个组件好还是多个组件好？什么时候需要拆分组件？组件嵌套规则如何来定？

场景1 —— 列表 + 表单
如果一个页面上既有列表数据又有表单数据（典型的CRUD页面），最好把表单（新增/编辑）视图单独创建为一个组件，否则表单中所绑定的变量在v-model触发的变化后会强制刷新根页面（组件）。此时如果你的列表中有大量数据（100条以上）或界面上有复杂的视图处理逻辑就会导致页面极度卡顿 —— 因为vue会认为你更新了视图上的变量，而实际上你更新的只是form中的变量，而form可能只是在新增/编辑时弹出的窗口或者抽屉。

场景2 —— 业务封装
所有人都知道input/select这些是所谓“可重用”组件，但在一个业务系统中，大多使用的是 “组件+业务数据” 这种组合。试想每个人都实现一次用户/部门/角色/...选择框会造成多少重复工作且不说很多业务数据的使用方式也有不同，比如下拉框或者弹出框。这些业务数据+原生组件就需要被封装为通用的业务组件，至于封装粒度要根据业务场景及数据的重用度来确定。

场景3 —— 特性封装
在实现弹出框选择时，我们一定会基于框架的Dialog组件来构建具体业务，比如用户选择

人员选择
这个选择框也同样基于UI框架的Dialog创建，但具有额外的右侧“多选”特性（可移除/可排序/重复检测/...）。如果其他业务也需要实现多选，也需要这些特性那就有必要将额外的特性封装为可重用组件，比如MultiSelectDialog
单位选择