computed

计算值(computed values)是可以根据现有的状态或其它计算值衍生出的值。 概念上来说，它们与 excel 表格中的公式十分相似。 不要低估计算值，因为它们有助于使实际可修改的状态尽可能的小。 此外计算值还是高度优化过的，所以尽可能的多使用它们。

可以将 UI 视图逻辑下沉到 Store 的背景

  • 运用 computed 天生具备的高度优化的优势，自动处理视图逻辑，效能有保障

  • computed 之后的值也只是对象而已，对于 React 而言都是一堆 ReactElement 或者 ReactComponent(集合)，由虚拟 DOM 渲染为真实的 DOM 节点的过程并不受任何影响

    关于将 UI 视图的 render 逻辑下沉到 Store 里处理的几个原因：

  • 减轻组件自身的逻辑

  • 非业务逻辑剥离组件本身维护，降低容器和内容之间的耦合性

    Example

  1. class DemoApi {
  2.   fetchData() {
  3.     return fetch("url");
  4.   }
  5. }
  7. class DemoStore {
  8.   constructor(api) {
  9.     this.api = api;
  10.   }
  11.   @observable data = [];
  13.   @action fetchData = async () => {
  14.     this.data = await this.api.fetchData();
  15.   };
  17.   @computed get listView() {
  18.     const onItemClick = () => {
  19.       //Item 的点击事件
  20.     }
  21.     return <List>
  22.       {this.data.map(d => <ListItem key={d.id} data={d} onClick={onItemClick}/>);}
  23.     </List>
  24.   }
  25. }
  28. @observer
  29. class Demo extends Component {
  30.   constructor(props){
  31.     super(props);
  32.     this.store = new DemoStore(new DemoApi());
  33.   }
  35.   render() {
  36.     return <div>{this.store.listView}</div>;
  37.   }
  38. }


当然，这样的代码组织方式使用于弱交互的组件场景，如果有非常复杂的交互逻辑，不适于将逻辑下沉到 Store 内部实现。
listView 的视图逻辑处理和 Demo 组件的解耦是的 Demo 组件代码简洁明了，易于阅读和维护（如果是容器组件，更可以通过传入不同的 store 挂载不同的 listView，达到复用的目的）。
Store 和 Api 拆分开，也是解耦的过程，好处在于代码职责分明、逻辑清晰、层次明朗、易于测试和维护。
如上示例代码展示：