reactjs - 如何使用Redux在Meteor App中加载数据？

Question

简介:

所以我在 Redux 上挣扎了很长时间。我想我现在确实理解了这个概念。本质上(并且相当简单):

1. 有一个存储区保存您所有应用程序的相关状态，
2. 用户与应用的交互可以触发具有以下特征的操作:描述性标题和一些数据负载
3. Reducer 使用Store中的当前状态和Actions负载将更新后的状态放入存储中(在旧状态之上)

现在这很好，因为我们可以将组件(甚至在 react 树的深处)与状态连接起来，并将状态用作单一事实来源(即始终知道用户是否登录)。

我的问题是在将 Redux 与 Meteor 结合使用时出现的，我仍然不清楚为什么以及想要将哪些信息放入 Meteor 应用程序中的 Redux 存储中。

<小时/>

示例:

假设我们有一个帖子集合。通常我们只会通过 Minimongo 获取并向用户显示结果。现在假设我们希望将 Redux 存储作为单一事实来源来保存所有数据。本质上必须将 minimongo 与 Redux 存储同步。据推测，人们会在 componentDidMount 上调度一个操作来将数据加载到存储中。

store.dispatch({
  type: 'GET_POSTS',
  posts: Posts.find().fetch(),
}); 

这将减少为:

const postReducer = (state = [], action) => {
  switch (action.type) {
    case 'GET_POSTS':
      return action.posts;
    default:
      return state;
  }
};

现在，为了使该商店保持最新状态，它必须与 Posts 集契约(Contract)步，大概是这样的(尽管我不完全确定我必须在代码中放置该跟踪器):

Tracker.autorun(() => {
  store.dispatch({
    type: 'GET_POSTS',
    posts: Posts.find().fetch(),
  });
});

现在我的主要问题是:如何避免 Redux 存储的大规模膨胀，因为根据我的理解，每当有人提交新帖子时，我们都会有当前状态 + 一个新状态(这本质上是当前状态+新帖子)。如果您有几个人来回发帖，即使您最初的帖子数量很大，这也可能会很快爆炸。

Answer 1

感谢您提出这个问题!上周我在一次培训中了解了 React + Redux，我很想将其添加到 Meteor 中。男孩，从那时起我就发现自己陷入了兔子洞!

我知道您已经熟悉 Redux。对于那些没有这样做的人，你一定要检查these videos .

正如我所言written earlier ,

I've become aware of two issues. These issues arise when you let all data (including Collections) flow through the Redux Store:

1. You loose out on Meteor reactivity (with vanilla Meteor, when the MongoDB updates, the data shown in the View also updates). Solution: We could write additional Redux actions & reducers on the server-side.
2. You loose out on Meteor optimistic UI (with vanilla Meteor, when you would add a new Widget, the client will already try to predict what it should look like even before the server responds). In the example here, while calling a Redux action (e.g. to add a Widget), we essentially wait for the Meteor method to insert the Widget in the collection before moving onto the Reducer which will update the Redux Store, who's State in turn updates our View. (Of course, all of this happens so quickly that you wouldn't notice it, but you might notice it if you were running it on a slow server or when you'd have a mobile application). Solution: We could write additional logic in the actions that update the Store immediately with the new Widget, and if it turns out we weren't authorized to call the Meteor method, we can still use, within the Action, the .catch of the Promise to adjust the Store (removing the Widget we already added).

So basically, by introducing Redux into our Meteor-React solution, we're missing out on two great features of Meteor. Both of them can be rebuilt using self-written logic, but it frankly seems a shame to do so.

我目前的看法:

• 对于不需要管理大量状态的相对简单的应用程序，只需不要将 Redux 引入您的 React-Meteor 堆栈即可。您会发现自己编写了更多额外的代码(即用于乐观的 UI 和服务器端更改)。 Meteor 通常首先处理的代码。
• 对于具有大量状态管理的更复杂的应用程序:Redux 似乎是当前 React 应用程序处理此问题的最佳方法之一。在这种情况下，将 Meteor 仅仅视为服务器可能是值得的。对 MongoDB 的调用应该始终通过 Meteor 方法，这些方法又从 Redux 操作中调用。 Meteor 方法绝对不应该从 Redux reducer 中调用，因为那将是 side effect 。 此时您可能想知道仍然使用 Meteor 的优势是什么 - 这是一个非常好的问题。

除此之外，我一直在考虑一种试图将两个世界的优点结合起来的架构。这样的架构仍然会使用 Meteor 的订阅/发布功能(这样你就可以保持乐观的 UI 和服务器端更改发送到客户端)，并使用 Redux Store 进行 UI 特定更改(想想过滤器按钮)。

一个更具体的例子:您可以通过应用程序内的 Meteor 发布/订阅来获取待办事项。但在实际将它们渲染到组件之前，您需要在中间添加一个过滤器函数。此过滤器功能取决于 Redux Store 对过滤器的说明。这又是由您按下的一些按钮定义的，这些按钮通过 Redux 操作和 reducer 传递到 Redux Store。