ReactJS Flux Utils 组件

Question

还有有趣的article
它描述了 Flux 中公开的 4 个主要类实用程序。

店铺

ReduceStore

MapStore(从 3.0.0 中删除)

容器

但是对于某些情况应该使用什么并不是很清楚。 ReduceStore 只有 2 个例子和 Container ，但不幸的是没有其他 sample 。

能否请您解释一下这 4 个组件的基本用法:当和 哪里它们应该在现实生活中使用吗？

扩展答案和代码示例将不胜感激!

更新:

MapStore已被removed从 3.0.0 开始

Answer 1

通过戳 code并通读方法文档，这是我可以解决的问题(我自己没有使用过这些类，因为我使用了其他 Flux 框架)。

以几乎相反的顺序进行这些实际上很有用。

容器

这不是 FluxStore 的子类因为毫不奇怪，它不是一家商店。 Container 是 React UI 组件的包装类，可自动从指定的存储中提取状态。

例如，如果我有一个 React 驱动的聊天应用程序，其中包含一个列出我所有登录好友的组件，我可能希望它从 LoggedInUsersStore 中拉取状态。 ，假设是这些用户的数组。

我的组件看起来像这样(源自他们提供的代码示例):

import {Component} from 'react';
import {Container} from 'flux/utils';

import {LoggedInUsersStore} from /* somewhere */;
import {UserListUI} from /* somewhere */;

class UserListContainer extends Component {
  static getStores() {
    return [UsersStore];
  }

  static calculateState(prevState) {
    return {
      loggedInUsers: LoggedInUsersStore.getState(),
    };
  }

  render() {
    return <UserListUI counter={this.state.counter} />;
  }
}

const container = Container.create(UserListContainer);

如果组件的注册存储更改状态，此包装器会自动更新组件的状态，并且通过忽略任何其他更改(即它假定组件不依赖于应用程序状态的其他部分)来有效地更新。

我相信这是 Facebook 的 React 编码原则的相当直接的扩展，其中 UI 的每一点都存在于一个高级“容器”中。由此得名。

何时使用

如果给定的 React 组件完全依赖于一些显式存储的状态。

如果是 不是 依赖于上面的 Prop 。容器不能接受 Prop 。

减少存储

一个 ReduceStore是一家完全基于的商店纯函数 --- 对其输入具有确定性的函数(因此相同的函数始终为相同的输入返回相同的内容)并且不会产生可观察到的副作用(因此它们不会影响代码的其他部分)。

例如，lambda (a) => { return a * a; }是 纯 : 它是确定性的，没有副作用。 (a) => { echo a; return a; }是 不纯 :它有副作用(打印 a)。 (a) => { return Math.random(); }是 不纯 : 它是不确定的。

目标与ReduceStore是简化:通过使您的商店是纯粹的，您可以做出某些假设。由于减少是确定性的，任何人都可以随时执行减少并获得相同的结果，因此发送 Action 流与发送原始数据几乎相同。同样，发送原始数据是完全合理的，因为您可以保证没有副作用:如果我的整个程序是由 ReduceStore 组成的s，并且我用另一个客户端的状态覆盖一个客户端的状态(调用所需的重绘)，我保证完美的功能。我的程序中的任何内容都不会因为操作而不是数据而改变。

无论如何，一个ReduceStore应该只实现其文档中明确列出的方法。 getInitialState()应该确定初始状态，reduce(state, action)应该转换 state给定 action (并且根本不使用 this:那将是不确定的/有副作用)和 getState() & areEqual(one,two)应该处理将原始状态与返回状态分开(以便用户不会意外修改它)。

例如，计数器将是一个明智的 ReduceStore :

class TodoStore extends ReduceStore {
    getInitialState() {
        return 0;
    }

    reduce(state, action) {
        switch(action.type) {
            case 'increment':
                return state + 1;
            case 'decrement':
                return state - 1;
            case 'reset':
                return 0;
            default:
                return state;
    }

    getState() {
        // return `this._state`, which is that one number, in a way that doesn't let the user modify it through something like `store.getState() = 5`
        // my offhand JS knowledge doens't let me answer that with certainty, but maybe:
        var a = this._state + 1;
        return a - 1;
    }
}

请注意，没有任何转换明确依赖于对象的当前状态:它们仅对 state 进行操作。他们被传递的变量。这意味着 store 的一个实例可以为同一个 store 的另一个实例计算状态。在 FB Flux 的当前实现中不是很有用，但仍然如此。

何时使用

如果你喜欢纯函数式编程(耶!)

如果您不喜欢使用基于该假设明确构建的框架 ( redux , NuclearJS )

并且您可以明智地编写一个纯粹功能性的商店(大多数商店可以，如果他们不能，那么多考虑一下架构可能是有意义的)

备注 :此类不能确保您的代码是纯函数式的。我的猜测是，如果您不亲自检查它就会损坏。

我会总是 使用这家商店。除非我可以使用...

FluxMapStore [已弃用]

这个类不再是 Flux 的一部分!

这是 ReduceStore 的子类.它适用于这种在内部恰好是 Maps 的纯功能商店。具体来说，Immutable.JS 映射(另一个 FB 东西!)。

他们有从状态中获取键和值的便捷方法:
WarrantiesStore.at('extended')而不是 WarrantiesStore.getState().get('extended') .

何时使用

如上，还有

如果我可以使用 map 代表这家商店。

助焊剂商店

这将我们带到 FluxStore :全能 Store 类和 Flux Store 概念的通用实现。

另外两家店是它的后代。

文档在我看来相当清楚它的用法，所以我会保留它

何时使用

如果不能使用另外两个Store util 类来保存您的数据

并且您不想开设自己的商店

就我而言，这永远不会:我更喜欢像 redux 和 NuclearJS 这样的不可变框架，因为它们对我来说更容易推理。我小心翼翼地以纯粹的功能方式构建我的商店。但如果你不这样做，这门课很好。