问题标签 [reactjs-flux]

我开发的一个应用程序最初是用 Flux 构建的。

然而，随着时间的推移，应用程序变得越来越难以维护。有非常多的动作。而且通常一个动作只能在一个地方（商店）听到。

Actions 使得不用在一个地方编写所有事件处理程序代码成为可能。所以代替这个：

我可以写：

但我从不那样使用动作。我几乎可以肯定，这不是我的应用程序的问题。

每次我调用一个动作时，我都可以调用store.onSmthHappen而不是action.smthHappen.

当然也有例外，当一个动作在多个地方处理时。但是当这种情况发生时，感觉就像出了什么问题。

如果我直接从商店调用方法而不是调用操作，那会怎样？我的应用程序不会那么灵活吗？不！只发生重命名（极少数例外）。但是要付出什么代价！使用所有这些操作来理解应用程序中发生的事情变得更加困难。每次跟踪复杂动作的处理时，我都必须在商店中找到处理它们的位置。然后在这些商店中，我应该找到调用另一个动作的逻辑。等等。

现在我来解决我的问题：

有些控制器直接从商店调用方法。如何处理操作的所有逻辑都在 Store 中。还存储对 WebAPI 的调用（通常一个存储与一个 WebAPI 相关）。如果事件应该在多个 Store 中处理（通常是顺序的），那么控制器会通过编排从 Store 返回的 Promise 来处理这个问题。自身私有方法中的一些序列（常用）。控制器的方法可以将它们用作处理的简单部分。所以我永远不会重复代码。

控制器方法不返回任何内容（单向流）。

实际上控制器不包含如何处理数据的逻辑。它只是点在哪里，以什么顺序。

您几乎可以在 Store 中看到数据处理的全貌。商店中没有关于如何与其他商店交互的逻辑（使用通量，它就像多对多关系，但只是通过动作）。现在 store 是一个高度内聚的模块，只负责领域模型（集合）的逻辑。

助焊剂的主要（在我看来）优势仍然存在。

因此，存在商店，它们是唯一真正的数据来源。组件可以订阅商店。并且组件调用与以前相同的方法，但不是actions使用controller. 与 React 的交互完全没有改变。

此外，事件处理变得非常明显。现在我可以看看控制器中的处理程序，一切都变得清晰起来，调试起来也容易得多。

问题是：

为什么动作是在不断变化的？我错过了他们的哪些优势？

我正在尝试在本地运行 ReactJS + CoffeeScript 应用程序，页面似乎在 JS 中加载，但没有显示任何内容（空白屏幕），控制台中显示错误

未捕获的 ReferenceError：未定义通量

这是似乎引起错误的代码片段。我们将 Flux 作为应用程序中节点模块的一部分。我看不出我应该在这里做什么。

请指导。

好吧，让我们来看看。我有一个包含多个项目的列表组件：

该列表组件包含保存在 Flux 存储中的状态（检查项目）并将其作为道具传递给项目。如果我在列表中并刷新浏览器，则存储数据（如此选定的状态）消失（没关系）。

如果我单击一个项目，然后返回，则列表状态（来自商店）被保留（良好）。

问题是，如果我单击一个项目，我刷新浏览器并返回列表，列表存储和状态都消失了（不是我想要的行为）。

我做错了什么吗？我看不到的简单解决方案？我想使用 SessionStorage 但即使刷新列表也会保留状态。

我正试图围绕 Facebook 的 Flux...

假设我有一个带有侧边菜单的应用程序，可以通过标题中的按钮隐藏和显示。

我的标题是一个组件，我的侧边菜单是另一个组件。

目前，我的 Header 组件只是在 HTML div 侧菜单元素上设置了一个类，它被 CSS 动画隐藏。

这里的总体思路是什么？

Flux 模型要求在视图中启动的任何状态更改都会触发通过调度程序工作的操作，并将存储向下传播回监听视图。

这一切都很好，花花公子。但是如果我需要在状态发生特定变化后执行一些 DOM 操作怎么办？在现实世界的应用程序中，我们有时必须使用那个，你知道的，称为jQuery 插件的遗物（还记得吗？）

例如，我需要在 Ajax 请求之后初始化一个 jQuery 视频播放器 à la 以$('#videoContainer').initPlayer(streamURL)检索。在继续阅读之前，请花点时间弄清楚如何使用Flux/React 做到这一点）。 streamURL

在视图部分，我可能会使用componentWillReceiveProps：

但是在这里，每次状态更新时，播放器都会被初始化。那肯定会破坏我们的视频播放器。因此，让我们在实际执行任何操作之前检查 URL 是否已更改：

容易，对吧？但是更大的图景呢？如果我们在添加更多功能和 UI 元素时将其放大并扩大范围会怎样，这可能会导致视图中出现更多自定义验证代码，以了解来自商店的内容。即使在一个完美的应用程序中，每家商店都有自己的领域，并且所有东西都以设计模式一尘不染，值得虔诚的追随者，随着应用程序的扩展，我们仍然必须在视图中使用越来越多的逻辑.

在我们的团队中，我认为这个逻辑应该真正进入符合 Flux 模型的 ControllerView 中——但其他人都认为这是框架应该处理的事情。我们是 Flux/React 的新手，对于如何让框架为我们做到这一点，我们想不出更好的主意。

作为具有良好实践 AngularJS 经验的开发人员，我如何调整我使用 React 在 Flux 中编写 Web 应用程序的心智模型？

我不是在寻找 Flux+React vs Angular 的答案（网上已经有很多了），但我想知道这两种“心态”的最大区别是什么：事先，我被介绍到The Angular Way；相对而言，什么是React Way？

当我离开 Angular 世界并过渡到 Flux 时，我需要开始关注哪些关键事项？

首先是差异，现在是相似之处：AngularJS 非常固执己见，并且有一些非常大的禁忌，比如 - 不要将 UI/DOM 代码放在控制器中。React 的最大禁忌和观点是什么？

最后但并非最不重要的一点是，Facebook 将 Flux 称为MVC 的替代品，但正如我所看到的那样——React 是视图引擎，商店是专注于单个域的模型容器，调度程序和动作形成一个控制器。那么这实际上不是具有不同名称的 MVC 吗？

我正在开发一个通量应用程序，并正在考虑采用immutable.js来维护状态。我看到 react 提供了自己的帮助器来更新不可变对象（http://facebook.github.io/react/docs/update.html），但不知道它与不可变自己的 setIn 和 updateIn 方法有什么不同（即，我已经可以将对象与 === 进行比较，以确定它们是否随 setIn 更改）。是否有理由将 react 助手与 immutable.js 一起使用？它只是语法糖吗？

TL;DR 是：

不同于

我目前正在使用通常与 ReactJS 相关的通量模式开发原型应用程序。

在 Facebook通量/聊天示例中，有两个商店，ThreadStore和UnreadThreadStore。后者提供了一个同步读取前者内容的getAll方法。

我们遇到了一个问题，即派生存储中的操作太昂贵而无法同步执行，并且理想情况下会委托给异步进程（Web Worker、服务器跳闸），我们想知道如何解决这个问题。

我的同事建议从吸气剂返回一个承诺，即

我对此并不完全满意。感觉就像是打破了模式，因为视图是变化的主要接受者，而不是商店。这是我们一直在探索的另一种途径 - 视图安装事件会发送一个更新派生数据的需求（如果需要）。

我喜欢这种方法的地方在于视图将 DerivedStore 视为它的视图模型，并且此类视图主要对其视图模型的新鲜度感兴趣。然而，我担心的是商店可能不同步。

那么我的问题：

• 承诺方法可以接受吗？
• 第二种方法更好/更差？如果是这样，为什么？
• 是否存在解决此问题的“规范”方法？

PS：抱歉，如果此代码中有任何基本的 linting 错误，我在过去 3 个月一直在 Coffeescript 工作，它破坏了我的 linting 能力......

我有一个与store通信的React 视图。我已经成功地分别测试了视图和商店，但没有组合在一起。

我遵循了此处记录的结构，但收到了TypeError。看起来 Jest 正在尝试将商店注册为组件，即使我使用dontMock.

我已经包含了我认为是下面的相关代码，但如有必要，可以完整提供。

查看笑话测试

谢谢！

我们正在重构一个大型 Backbone 应用程序以使用 Flux 来帮助解决一些紧密耦合和事件/数据流问题。但是，我们还没有弄清楚如何处理需要知道特定 ajax 请求状态的情况

当控制器组件从通量存储请求一些数据，并且该数据尚未加载时，我们触发 ajax 请求来获取数据。我们在发起请求时调度一个动作，在成功或失败时调度另一个动作。

这足以加载正确的数据，并在加载数据后更新存储。但是，在某些情况下，我们需要知道某个 ajax 请求是挂起还是完成 - 有时只是为了在一个或多个视图中显示微调器，或者有时在加载数据之前阻止其他操作。

人们在通量/反应应用程序中使用这种行为的任何模式吗？以下是我考虑过的几种方法：

1. 拥有一个“请求状态”存储，它知道是否存在任何类型的未决、已完成或失败的请求。这适用于简单的情况，例如“是否有未决的锻炼数据请求”，但如果我们想要更细化“是否有未决的锻炼 id 123 请求”，则变得复杂

2. 让所有商店跟踪相关数据请求是否处于待处理状态，并将该状态数据作为商店 api 的一部分返回 - 即 WorkoutStore.getWorkout 将返回类似 { status: 'pending', data: {} } 的内容。这种方法的问题在于，这种状态似乎不应该与域数据混合，因为它确实是一个单独的问题。此外，现在锻炼商店 api 的每个消费者都需要处理这种“状态响应”，而不仅仅是相关的域数据

3. 忽略请求状态 - 数据存在且控制器/视图对其进行操作，或者数据不存在且控制器/视图不对其进行操作。更简单，但可能不足以满足我们的目的