问题标签 [reactjs-flux]

我有这个集合的模型和列表视图的主干集合。

当用户单击复选框时，我执行此代码

调度程序中的这个动作触发事件save-model，这里的问题是 - 谁应该处理这个事件？

我有两个选择：

1) 收藏

2）集合中的每个模型都应该听dispathcer

我正在尝试将 ImmutableJS 与我的 React / Flux 应用程序一起使用。

我的商店是Immutable.Map对象。

我想知道我应该在哪一点使用.toJS()？应该是商店.get(id)退货的时候吗？或在组件中.get('member')？

我正在为 react+flux 应用程序中的商店编写单元测试。我按照此处设置模拟调度程序的示例进行操作，我的单元测试如下所示：

在我的 item_store.coffee 文件中，我向调度员注册，如下所示：

我希望模拟的 Dispatcher 注册回调，因为这发生在实际的 item_store 文件中，我告诉 jest 不要模拟。但是，由于 ShopDispatcher.register 是未定义的，它没有被注册，但我不太清楚为什么。任何帮助表示赞赏。

在我的应用程序中，我对一条数据进行了两次 ajax 调用。首先，我拨打电话以获取ecommerceIntegrations. 一旦我有了这些，我就可以抓住它们各自的orders.

我当前的代码如下所示：

我正在尝试遵循 Facebook 的 Flux 模式，我很确定这不会遵循它。我看到其他一些关于使用 Flux 嵌套数据的 SO 帖子，但我仍然不明白。任何指针表示赞赏。

我有一个 React.js 应用程序，我正在重构它以使用 Flux 架构，并且正在努力弄清楚在坚持 Flux 模式的同时错误处理应该如何工作。

当前，当遇到错误时，会触发 jQuery 事件“AppError”，并且订阅此事件的通用错误处理帮助器会在用户屏幕上放置一条 Flash 消息，登录到控制台，并通过 API 调用报告它。好的是我可以从应用程序的任何部分以任何原因触发错误，并以一致的方式处理它。

我似乎无法弄清楚如何在 Flux 架构中应用类似的范例。这是我正在努力解决的两个特殊情况。

1) API 调用失败

我所有的 API 调用都是由动作创建者发出的，并且我使用承诺在失败时调度错误事件（IE 'LOAD_TODOS_FAILED'）。商店看到这个事件并相应地更新它的状态，但我仍然没有我之前迭代的一般错误行为（通知等）。

可能的解决方案：

我可以创建一个绑定到 'LOAD_TODOS_FAILED' 操作的 ErrorStore，但这意味着每次我遇到新类型的错误时，我都需要将该操作显式添加到 ErrorStore，而不是自动处理所有错误。

2) Store 收到意外动作

这是我真正感到困惑的一个。我想处理当一个动作被分派到一个 Store 的情况下，这在 Store 的当前状态下没有意义。我可以处理 Store 中的错误以清理状态，但仍然可能想触发一个意外发生的错误。

可能的解决方案：

1. 从商店发送一个指示错误的新操作。

   我相信商店不应该调度操作（如果我错了，请告诉我），我仍然遇到与上述 API 错误相同的问题。

2. 为订阅每个 Store 的错误处理创建一个 ControllerView

   我可以在每个 store 上定义一个 errors 属性，然后让一个 View 监视每个 Store 并且只对 errors 属性进行操作。当 errors 属性不为 null 时，它可以调度新的操作等。缺点是我需要记住，每当创建新的 Store 时，我都需要将每个 Store 添加到此视图中，并且每个 Store 都必须有一个行为相同的错误属性方法。它也没有解决 API 调用失败的问题。

有没有人有适合 Flux 架构的通用错误处理程序的建议方法？

TL;博士

我需要处理大多数 Action Creators 和 Stores 中的错误。如何设置任何类型的通用错误都会发生的一致错误处理？

我想用反应显示一个可选择的对象列表。我有列表组件，它拥有几个组，这些组拥有几个元素。显然，列表数据本身应该进入存储，但是 UI 状态（例如，选择了哪个元素）呢？它表面上是根列表元素的一个属性，但要将其传递给元素，链上的每个元素（好吧，在这种情况下只有 1 个 - 组）都需要传递它，即使他们不关心它。如果我想添加另一个属性，我需要相当冗长地将它传递到链中。

还有，封装。如何制作一个可能使用不同数据多次实例化的组件？

在其他语言中，我只会将列表指针传递到链中，以便子元素可以从中获得任何他们想要的东西，所以一切都保持封装。通量方式是将商店传递给子元素吗？你会为 UI 状态和持久数据单独存储吗？

我正在尝试向我的 Flux 模型添加乐观更新。我将 UI 操作分派和服务器操作分派合并为一个操作。我在动作创建器中的代码如下所示：

这是允许乐观更新的适当方式还是我对这篇文章的看法不正确？

我正在使用 ReactJS 使用 Facebook Flux（我使用的是 Fluxxor，但我认为这并不重要），到目前为止，我认为它们是在应用程序中处理数据流的好方法。然而，有一件事我真的很难理解。可能这只是 Flex 不应该做的事情，或者我遗漏了一些明显的东西，但因此我问...

例如，我正在构建一个用于登录的系统。非常简单——弹出一个登录对话框，输入用户名和密码并按下按钮。这会调用 LoginAction.login(username, password) Action Creator，它将 LOGIN 事件发送到 Dispatcher，然后触发 API 调用以验证用户身份并确保凭据正确。如果我们从 API 获得成功，那么我们会触发 LOGIN_SUCCESS 事件到 Dispatcher，SessionStore 会处理这个并存储我们已经成功登录的事实，以及我们是谁的详细信息。然后，这会触发 UI 的某些部分进行更新 - 例如，“登录”按钮更改为“Hello Graham”文本，并改为“注销”按钮。这一切都非常简单，而且有效且有意义。

我遇到的问题是登录失败时。如果我输入了无效的用户名/密码，那么我希望登录对话框告诉用户这一点，以便他们可以更正输入的内容并重试。我能想到的唯一方法是向 Dispatcher 发送一个 LOGIN_FAILED 事件，然后由一些 Store 处理，该 Store 存储最后一个登录错误以供 Dialog 显示。但这只是感觉很奇怪，因为这些错误不是应用程序状态，而是有关失败的请求的传递信息，然后用户将更正并重试。

在我看来，这种传递状态将在 API 调用中非常常见，因为用户输入可能会失败，因此不属于应用程序状态的一部分，而是属于其他地方。但是，我无法弄清楚 Flux 如何允许这种传递状态返回到 UI 以显示给用户......

我实际上正在研究 ReactJS 和 Flux 架构，但我并不真正理解其中的“Store”部分到底是什么。

它到底是什么？一个数据库？本地存储文件？

感谢提前

这更像是“您的意见/我的想法是否正确？” 问题。

在理解 Flux 的同时尽可能严格，我试图找出 XHR 调用的位置、websockets/外部刺激的处理、路由发生等。

从我读到的文章、采访和浏览 facebook 示例中，有几种方法可以处理这些事情。严格遵循 Flux，Action 创建者是执行所有 XHR 调用的人，可能会PENDING/SUCCESS/FAILURE在请求完成之前和之后触发 Action。
另一个是，来自 facebook 的 Ian Obermiller，所有 READ(GETs) 请求都由 Stores 直接处理（不涉及 Action 创建者/调度程序），而 WRITE(POSTs) 请求由 Action Creator 处理整个action>dispatcher>store流程。

我们得出/希望坚持的一些理解/结论：

1. 理想情况下，任何进出系统的事情都只能通过 Actions 发生。
2. 离开/进入系统的异步调用将具有PENDING/PROGRESS(think file uploads)/SUCCESS/FAILURE操作。
3. 跨整个应用程序的单个调度程序。
4. Action>Dispatcher>Store调用是严格同步的，以坚持调度不能在内部启动另一个调度以避免链接事件/动作。
5. 商店跨视图持久化（考虑到它是一个单页应用程序，您希望能够重用数据）

我们得出了一些结论，但我并不完全满意：

1. 如果您采用 Store 进行读取和操作写入的方法，您如何处理多个 Store 可能能够使用来自单个 XHR 调用的数据的情况？
   示例：TeamStore 发出的 API 调用/api/teams/{id}返回如下内容：

   理想情况下，我还想使用此 API 中返回的信息更新 MemberStore。我们为每个在更新记录时更新的实体维护一个版本号，这是我们在内部使用的拒绝对陈旧数据的调用等。使用它，我可以有一个内部逻辑，如果我作为副作用其他一些 API 调用，我知道我的数据已经过时，我触发了对该记录的刷新。
   看起来，解决方案是您需要商店来触发一个操作（这将有效地更新其他依赖商店）。这会将 Store>View>Action 短路到 Store>Action，我不确定这是否是个好主意。我们已经有一件事情与 Stores 自己的 XHR 调用不同步。像这样的让步最终会开始蔓延到整个系统。
   或了解其他商店并能够与之通信的商店。但这打破了商店没有二传手的规则。

   2. 上述问题的一个简单解决方案是您坚持将动作作为外部传入/传出刺激发生的唯一地方。这简化了多个 Store 更新的逻辑。
      但是现在，您在哪里以及如何处理缓存？我们得出的结论是，缓存将发生在 API Utils/DAO 级别。（如果您查看通量图）。
      但这引入了其他问题。为了更好地理解/解释我的意思：

      • /api/teams返回我显示所有团队列表的所有团队的列表。

      • 单击团队的链接时，我会转到其详细信息视图，/api/teams/{id}如果商店中尚不存在该数据，则该视图需要数据。
        如果 Actions 处理所有 XHR，则 View 会执行类似TeamActions.get([id])which does的操作TeamDAO.get([id])。为了能够立即返回这个调用（因为我们已经缓存了它），DAO 必须进行缓存，但还要维护集合/项目之间的关系。按照设计，这种逻辑已经存在于商店中。
        问题来了：

      • 你是否在 DAO 和 Stores 中重复了这个逻辑？

      • 你是否让 DAO 知道 Stores，他们可以询问 Store 是否已经有一些数据，然后返回 302 说，你有最新的数据很好。

   3. 您如何处理涉及 XHR API 的验证？一些简单的事情，比如重复的团队名称。
      视图直接命中 DAO 并执行类似TeamDAO.validateName([name])返回承诺的操作，或者您是否创建了操作？如果您创建一个动作，考虑到其主要是瞬态数据，通过该动作，有效/无效是否会流回视图？

   4. 你如何处理路由？我查看了 react-router，但我不确定我是否喜欢它。我不一定认为完全需要强制采用 react-ish JSX 方式来提供路由映射/配置。此外，显然，它使用了自己的 RouteDispatcher，它执行单一调度程序规则。
      我更喜欢的解决方案来自一些博客文章/SO 答案，其中您将路由映射存储在 RouteStore 中。
      RouteStore 还维护 CURRENT_VIEW。react AppContainer 组件在 RouteStore 中注册，并在更改时将其子视图替换为 CURRENT_VIEW。当前视图在完全加载时通知 AppContainer，并且 AppContainer 触发 RouteActions.pending/success/failure，可能带有一些上下文，以通知其他组件达到稳定状态，显示/隐藏繁忙/加载指示。

   我无法干净设计的事情是，如果您要设计类似于 Gmail 的路由，您会怎么做？我非常喜欢对 Gmail 的一些观察：

   • 在页面准备好加载之前，URL 不会更改。它在“加载”时停留在当前 URL 上，并在加载完成后移动到新 URL。这使得它......
   • 失败时，您根本不会丢失当前页面。因此，如果您正在撰写，并且“发送”失败，您不会丢失您的邮件（即您不会丢失当前稳定的视图/状态）。（他们不这样做，因为自动保存是 le pwn，但您明白了）您可以选择将邮件复制/粘贴到某个地方以安全保存，直到您可以再次发送。

   一些参考资料：
   https ://github.com/gaearon/flux-react-router-example http://ianobermiller.com/blog/2014/09/15/react-and-flux-interview/ https://github。 com/facebook/flux