何时不在React-Native中使用Redux？

Question

我最近开始研究React-Native Apps，发现Redux很有帮助。 但根据我的理解，当我使用Reducers （主要用于使用WebServices API）时，数据存储在App级别状态，可供Components 。 由于所有数据都处于应用级别状态，因此App性能不会很苛刻。 我在这里很困惑。 请推荐一个出路。 谢谢

Answer 1

Redux单店不应影响您的应用程序性能。 唯一的区别是所有状态对象都嵌套在一个树中，而不是存储在多个不同的嵌套组件中。
相反，真正影响React应用程序性能的是渲染过程。 在React中，不断更新组件本地状态或道具可能会导致性能下降，这是由于后续的，有时是无用的重新呈现。 如果您真的关心Redux的性能，那么本文可以涵盖您的大多数疑问，并为您提供一些有用的见解。

Answer 2

是的，数据将处于全局状态。 这就是整个想法。 要在两个组件之间共享数据，我们需要将状态提升到公共父组件。 对于复杂的应用程序，仍会导致数据流问题。 Redux通过将状态一直提升到全局状态容器来解决数据流问题。 从redux存储中，状态通过props流向所有组件。 这鼓励了React应用程序中的单向数据流。 通过调度操作对Redux存储进行任何状态更改。 从全球状态来看，数据流向容器和表示组件。

应用程序性能通常不是问题。 我知道人们使用100多个减速器，性能很好。 对于表单，最好为TextInput设置一些本地状态。 并使用onBlur将状态保存到redux存储。

什么时候不使用Redux？ 对于只有几个屏幕的简单应用程序，Redux可能是一种矫枉过正。 您需要为简单应用程序执行的操作就是在根组件或容器组件中具有所有状态，并让它向下流向表示组件。 如果您熟悉Redux，您仍然可以使用Redux。 没有伤害。 但易于使用本地状态的更简单的应用程序。

Answer 3

正如我所看到的（仅限我的意见）：

• Redux / Flux /功能编程
  • 更多碎片整理的逻辑（存储，操作，缩减器，视图，视图控制器，中间件）。 更难重用部分应用程序（需要复制和编辑大量源代码文件）
  • “白盒子”的逻辑。 单向执行流程，用于测试操作，状态和复制问题的强大工具
  • 更难处理多线程，但仍然可能。 需要使用功能性操作。
  • 在客户端上执行更多逻辑（Facebook开发它的原因之一）
  • 非常适合大型或协作UI应用程序
• MVC / OOP
  • 更统一的逻辑（模型，视图，控制器）。 重用部分应用程序要容易得多。
  • “黑匣子”的逻辑。 执行流程无法控制。 可能最终陷入死锁，无限循环，难以复制状态和问题。
  • 更容易处理多线程。
  • 在服务器上执行更多逻辑
  • 结构非常适合小型或可重用的UI应用程序

关于非UI应用程序：OOP更适合制作可重用的非UI库或没有事务/事件性质的应用程序。 目前，几乎所有非UI应用程序的库仍然使用OOP构建。 结合这两个世界会让生活变得困难。 也许在将来，一切都会改变，但就目前而言，我不建议将Redux / Flux用于非UI应用程序。