在什么情况下有充分的理由使用 RxSwift 和 RxCocoa？
In which situation good reason to use RxSwift & RxCocoa?
前几天开始学习RxSwift，但是越写代码越看不懂哪些情况需要用响应式编程，我可以不用RxSwift写同样的代码，用NotificaitionCenter，delegate模式, Grand Central Dispatch, 关闭。
我了解到 RxSwif 和 RxCocoa 提供了下一个机会：
There are some different ways to pass information from one object to
another in iOS reactively (Notification, pass in closure, delegate,
KVO, & target/action,) each of these different systems may be simple
by itself but most of the complexity in the logic of an iOS app is in
having to convert from one of these systems to another.
RxSwift/RxCocoa replaces virtually all of these systems with one which
is in a Rx way.
但是当我尝试在 Rx 上编写代码时，我发现这段代码并不容易理解。
也许有人可以举例说明何时需要在应用程序中使用 Rx，或者在大多数情况下不需要使用 Rx，因为代码理解起来会很复杂，我很喜欢 Rx 的知识，但并不完全理解需要用的时候的好情况。
好吧，它和其他工具一样。有些人使用它是因为您最终编写的代码比其他方式少。它确实有一个陡峭的学习曲线，但如果项目需要它（项目已经使用它，并且相关人员希望继续使用它），它可能很有价值。
我在一家有 RxSwift 项目的公司工作。所有架构都是围绕 RxSwift 构建的，所有代码都必须使用 RxSwift 编写。代码没有使用 RxSwift 时那么复杂。主要问题是很难让新开发人员加入该项目，因为正如我之前所说，Rx 的学习曲线非常陡峭。最后，出于这个原因，他们决定开始从 Rx 转向更经典的方法。
我也为完全拒绝 RxSwift 的公司工作，因为他们不希望在他们的应用程序中有另一个第三方依赖。
所以归根结底，这只是一个偏好问题。就个人而言，我确实看到了 Rx 的好处和简洁性，但更喜欢尽可能少地使用第三方依赖项。
要真正获得 Rx 的好处，您必须在项目中大量使用它并围绕它构建架构。与其他 3rd 方库不同，您不能只是在 RxSwift 周围放置一个包装器，以防它消失并且您决定用其他东西替换它。但话又说回来，Rx 在所有平台和编程语言上的传播如此之广，我认为它不会很快消失。
长话短说，使用它，看看你是否喜欢。如果没有，至少如果您碰巧开始从事使用它的其他人的项目，那么知道它是件好事。
既然你在问题中引用了我的话，我想我应该提供一个答案...
经典的例子是搜索...写一个视图控制器，允许用户输入文本，然后发出网络请求，然后将结果解码为字符串数组，然后将结果显示在table 查看。
为了在没有 Rx 的情况下做到这一点，您需要协调来自两个委托、两个闭包和两个状态变量的三个方法。重要的是，您不会在代码中的任何地方看到任何与上面的句子相似的东西。
使用 Rx 实现的这个功能是从搜索文本字段到网络请求到解码器再到 table 视图的直线代码。就像需求描述一样
所以这不仅仅是需要更少代码的问题。这是一个不再需要协调绝望的通信系统的问题。这是一个用单个代码块（或至少更少的代码块）来表示一个功能的问题。
前几天开始学习RxSwift，但是越写代码越看不懂哪些情况需要用响应式编程，我可以不用RxSwift写同样的代码，用NotificaitionCenter，delegate模式, Grand Central Dispatch, 关闭。
我了解到 RxSwif 和 RxCocoa 提供了下一个机会：
There are some different ways to pass information from one object to another in iOS reactively (Notification, pass in closure, delegate, KVO, & target/action,) each of these different systems may be simple by itself but most of the complexity in the logic of an iOS app is in having to convert from one of these systems to another. RxSwift/RxCocoa replaces virtually all of these systems with one which is in a Rx way.
但是当我尝试在 Rx 上编写代码时，我发现这段代码并不容易理解。
也许有人可以举例说明何时需要在应用程序中使用 Rx，或者在大多数情况下不需要使用 Rx，因为代码理解起来会很复杂，我很喜欢 Rx 的知识，但并不完全理解需要用的时候的好情况。
好吧，它和其他工具一样。有些人使用它是因为您最终编写的代码比其他方式少。它确实有一个陡峭的学习曲线，但如果项目需要它（项目已经使用它，并且相关人员希望继续使用它），它可能很有价值。
我在一家有 RxSwift 项目的公司工作。所有架构都是围绕 RxSwift 构建的，所有代码都必须使用 RxSwift 编写。代码没有使用 RxSwift 时那么复杂。主要问题是很难让新开发人员加入该项目，因为正如我之前所说，Rx 的学习曲线非常陡峭。最后，出于这个原因，他们决定开始从 Rx 转向更经典的方法。
我也为完全拒绝 RxSwift 的公司工作，因为他们不希望在他们的应用程序中有另一个第三方依赖。
所以归根结底，这只是一个偏好问题。就个人而言，我确实看到了 Rx 的好处和简洁性，但更喜欢尽可能少地使用第三方依赖项。
要真正获得 Rx 的好处，您必须在项目中大量使用它并围绕它构建架构。与其他 3rd 方库不同，您不能只是在 RxSwift 周围放置一个包装器，以防它消失并且您决定用其他东西替换它。但话又说回来，Rx 在所有平台和编程语言上的传播如此之广，我认为它不会很快消失。
长话短说，使用它，看看你是否喜欢。如果没有，至少如果您碰巧开始从事使用它的其他人的项目，那么知道它是件好事。
既然你在问题中引用了我的话，我想我应该提供一个答案...
经典的例子是搜索...写一个视图控制器，允许用户输入文本，然后发出网络请求，然后将结果解码为字符串数组，然后将结果显示在table 查看。
为了在没有 Rx 的情况下做到这一点，您需要协调来自两个委托、两个闭包和两个状态变量的三个方法。重要的是，您不会在代码中的任何地方看到任何与上面的句子相似的东西。
使用 Rx 实现的这个功能是从搜索文本字段到网络请求到解码器再到 table 视图的直线代码。就像需求描述一样
所以这不仅仅是需要更少代码的问题。这是一个不再需要协调绝望的通信系统的问题。这是一个用单个代码块（或至少更少的代码块）来表示一个功能的问题。