Question

几乎所有的通量示例都涉及客户端的数据缓存，但我认为我不能在我的很多应用程序中执行此操作。

在系统中我正在考虑使用React / Flux，单个用户可以拥有我们存储的数千个主要数据（并且1个记录可能至少有75个数据属性）。在客户端缓存这么多数据似乎是一个坏主意，可能会使事情变得更复杂。

如果我没有使用Flux，我只会有一个类似ORM的系统，可以与REST API通信，在这种情况下，userRepository.getById(123)之类的请求总是会触及API，无论我是否在最后请求数据页。我的想法是让商店有这些方法。

Flux是否认为如果我要求数据，它总是命中API并且从不从本地缓存实例中提取数据？如果大多数数据检索请求总是会遇到API，我能否以某种方式使用Flux？

Answer 1

最接近你没有缓存的是当请求新数据的操作进入时，将任何商店状态重置为null或[]。如果这样做，必须发出更改事件，或者你邀请竞争条件。

作为flux的替代方法，您可以简单地使用promises和简单的mixin与api来修改状态。例如，使用bluebird：

var promiseStateMixin = {
  thenSetState: function(updates, initialUpdates){
    // promisify setState
    var setState = this.setState.bind(this);
    var setStateP = function(changes){
        return new Promise(function(resolve){
            setState(changes, resolve);
        });
    };

    // if we have initial updates, apply them and ensure the state change happens
    return Promise.resolve(initialUpdates ? setStateP(initialUpdates) : null)
      // wait for our main updates to resolve
      .then(Promise.params(updates))
      // apply our unwrapped updates
      .then(function(updates){
          return setStateP(updates);
      }).bind(this); 
  }
};

在你的组件中：

handleRefreshClick: function(){
  this.thenSetState(
      // users is Promise<User[]>
      {users: Api.Users.getAll(), loading: false}, 

      // we can't do our own setState due to unlikely race conditions
      // instead we supply our own here, but don't worry, the
      // getAll request is already running
      // this argument is optional
      {users: [], loading: true}
   ).catch(function(error){
      // the rejection reason for our getUsers promise 
      // `this` is our component instance here
      error.users 
   });
}

当然，这并不能阻止您在应用程序中使用通道时/使用通道。例如，react-router用于许多反应项目，并在内部使用flux。 React和相关的库/模式被设计为仅在需要时提供帮助，并且永远不会控制您编写每个组件的方式。

Answer 2

我认为在这种情况下使用Flux的最大好处是，您的应用程序的其余部分不必关心数据从未被缓存，或者您正在使用特定的ORM系统。就组件而言，数据存储在商店中，数据可以通过操作进行更改。您的操作或商店可以选择始终转到API获取数据或在本地缓存某些部分，但您仍然可以通过封装此魔法获胜。

没有数据缓存的流量？

2 个答案: