Reactivecocoa: 将 Rex 迁移到 ReactiveCocoa 组织

我赞成将 Rex 转移到 ReactiveCocoa 组织。 它最初是一个个人游乐场，但后来演变成更有用的东西。 我也不再在日常工作中使用 RAC，因此将所有权交给社区是有道理的。

在扣动扳机之前，我想知道@NachoSoto和@mdiep 对此有何感受。

我会完全参与。我建议进行一次通过/快速代码审查（我很乐意这样做）以确保操作员/实现符合标准（我不怀疑它一秒钟知道@neilpa虽然:)），但只是为了确保我们：

• 知道我们需要维护哪些操作符（可能删除一些？idk）。
• 确保我们确定需要改进的领域和未解决的问题。

如果使图书馆更易于访问是目标，我建议使用更正式的名称可能会有所帮助。 当我看到“Rex”时，并没有想到 ReactiveCocoa。 不确定正确的名称是什么，但是名称中带有“ReactiveCocoa”甚至只是“Reactive”的名称会更好。

我还没有真正看过 Rex，但我喜欢 ReactiveCocoa 组织下的一个以 UI 为中心的库的想法。 Rex 似乎是一个好的开始。 👍 我认为让@NachoSoto先看看也是个好主意。

我确实认为我们需要为 RAC 找到更多的核心贡献者。 似乎每个人都被分散得很薄。

@tonyarnold这可能会有所帮助。 ✨

@mdiep我同意。 尽管如此，Rex 还是需要在文档（README）方面做一些工作。 也许创建一个目录，这样人们就知道它提供了什么样的 UI 绑定，而不必检查源代码。 当然还有杂项运算符，也应该记录在案。

我确实认为我们需要为 RAC 找到更多的核心贡献者。 似乎每个人都被分散得很薄。

我也同意这一点，这里还有很多工作要做：

1. 修改未解决的问题。
2. 也许添加更多的用法示例，就像它在这里完成并有一个文档。 我曾尝试使用RACNest来实现这一点，但不是使用代码片段，而是使用交互式项目。
3. 关闭或更新一些废弃的项目（如this 、 this和this ）。 也许@jspahrsummers可以与我们分享他在这些项目上的观点。
4. 可能开始加快速度并做一些类似于 RxSwift 在这里所做的事情（例如，我们可以为Alamofire 之类的东西创建绑定）。 这可能是一项相当大的工作量，但它也会吸引新人加入该框架（我认为这是 RxSwift 越来越受欢迎的原因之一）。

我很乐意在需要的地方提供帮助，因为我在当前的工作中使用 Rex 和 ReactiveCocoa。

@RuiAAPeres在使用和推广 ReactiveCocoa 和 Rex 方面付出了巨大的努力，我认为他可以成为一个很好的核心贡献者。 我认为要使当前绑定现代化，但也需要提供新绑定，还有很多工作要做，他可能是实现这一目标的好资产。

我还在我目前的工作中使用 ReactiveCocoa 和 Rex，所以我也可以提供任何我能提供的帮助并感兴趣。

仅供参考，我在我的个人游乐场https://github.com/inamiy/ReactiveCocoaCatalog/pull/8 中添加了 Rex 演示。
到目前为止真的很好的代码，我认为第一步迁移到 org 就足够了：sparkles：

让 Rex 成为 ReactiveCocoa 的正式组成部分是个好主意。 由于 Swift 可以很容易地将代码拆分为多个模块，从而将核心功能保留在主模块中，并为特定于 UI 的扩展引入第二个模块绝对是有意义的。

我建议进行以下更改：

• 重命名 Rex 以表明它是 ReactiveCocoa 的扩展，并且它（主要）是关于 UI（如@tonyarnold 所述）
• 将前缀rex_xxx更改为rac_xxx以使命名一致

@lukaskubanek我同意第一点，但我对以下几点看法不一：

将前缀 rex_xxx 更改为 rac_xxx 以使命名一致

虽然它会保持命名一致，但使用不同的名称，恕我直言，有几个优点：

1. 假设我需要这两个库，我可能会在项目开始时包含这两个库。 最终，随着项目的发展，我可能会停止使用 Rex 的任何运算符。 在项目中快速搜索rex_将帮助我确认并将其作为依赖项删除。
2. 如果某个操作员有奇怪的行为，我会立即知道在哪个项目中打开问题（作为问题或错误）。
3. 它可以帮助初学者了解哪些是核心操作符，以及所有其他操作符的构建基础。

我们已经讨论过将核心 Swift 代码、Obj-C 代码和 Swift <-> Obj-C 桥移到单独的 repos (#2807) 中，将这个 repo 留给 Cocoa 绑定......所以我认为我们应该移动 Rex将代码作为 RAC 5 写入此存储库。

@neilpa @NachoSoto你怎么看？

Rex 和 Swift 绑定对 ReactiveCocoa ObjC API 的依赖是否会在分离期间被移除，即在 Swift 中重新实现？ 否则，拆分 IMO 在维护之外不会真正有效，因为 Swift 用户仍然需要为几个桥接方法构建整个 ObjC 库。

Rex 和 Swift 绑定对 ReactiveCocoa ObjC API 的依赖是否会在分离期间被移除，即在 Swift 中重新实现？

是的！ 它肯定会涉及一些 Objective-C，但不会涉及 ReactiveObjC。

所以我认为我们应该将 Rex 代码作为 RAC 5 移动到这个存储库中。

同意，但我们需要小心回购历史。 我们应该制定一个计划来管理移动/rebase/split，以保持合理的回购历史。

对于我们没有潜在的subtree split选项的未决问题也有影响。

我想这已经完成了，感谢#3210！