Reactivecocoa: RexをReactiveCocoa組織に移動する

RexをReactiveCocoa組織に移行することに賛成です。 それは個人的な遊び場として始まりましたが、より便利なものに変わりました。 また、私は日常業務でRACを使用しなくなったため、コミュニティに所有権を与えることは理にかなっています。

トリガーを引く前に、 @NachoSotoと@mdiepがそれについてどのように感じているか知りたいです。

私は完全に参加します。演算子/実装が標準に達していることを確認するために、パス/クイックコードレビュー（私はそれを喜んで行います）を行うことをお勧めします（私はそれを疑うことはありません@neilpaを知っている1秒:)）、しかし念のために：

• どの演算子を維持する必要があるかを認識しています（おそらくいくつかの？idkを削除します）。
• 改善の領域と未解決の問題を特定するようにしてください。

ライブラリをよりアクセスしやすくすることが目標である場合は、より正式な名前が役立つ可能性があることをお勧めします。 「レックス」は、私がそれを見たときにReactiveCocoaを思い起こさせません。 正しい名前が何であるかはわかりませんが、名前に「ReactiveCocoa」または単に「Reactive」が含まれているものの方がIMOの方が優れています。

私はRexを実際には見ていませんが、ReactiveCocoa組織の下にあるUIに焦点を合わせたライブラリのアイデアが好きです。 レックスはそれへの良いスタートのようです。 👍 @NachoSotoに最初に見てもらうのも素晴らしいアイデアだと思います。

一般的に、RACのコア貢献者をさらに見つける必要があると思います。 みんなかなり薄く広がっているようです。

@tonyarnoldそれは助けることができます。 ✨

@mdiep同意します。 それでも、Rexはドキュメント（README）に関して少し作業が必要です。 たぶん、カタログを作成して、ソースコードをチェックする代わりに、カタログが提供するUIバインドの種類を人々が知っているようにします。 もちろん、その他の演算子もありますが、これも文書化する必要があります。

一般的に、RACのコア貢献者をさらに見つける必要があると思います。 みんなかなり薄く広がっているようです。

私もこれに同意します。ここで行うべき作業がかなりあります。

1. 未解決の問題を修正します。
2. ここで行ったように、使用例をさらに追加して、そのためのドキュメントを用意してください。 私はRACNestでそれを試みましたが、コードの断片の代わりに、インタラクティブなプロジェクトでそれを試みました。
3. 放棄されたプロジェクトの一部を閉じるか更新します（ this 、 this 、 thisなど）。 たぶん@jspahrsummersはこれらのプロジェクトに関する彼のPOVを私たちと共有することができます。
4. 潜在的にスピードを上げ始め、RxSwiftがここで行ったことと同様のことを行います（たとえば、 Alamofireなどのバインドを作成できます）。 これはかなりの作業になるかもしれませんが、フレームワークに新しい人々を引き付けることにもなります（これが、RxSwiftの人気が高まっている理由の1つだと思います）。

私は現在の仕事でRexとReactiveCocoaを使用しているので、必要な場所で喜んでお手伝いします。

@RuiAAPeresは、ReactiveCocoaとRexの使用と宣伝に多大な努力を払ってきました。彼は、優れたコア貢献者になることができると思います。 現在のバインディングを最新化するだけでなく、新しいバインディングを提供するためにやるべきことはまだたくさんあると思います。彼はそれを達成するための良い資産かもしれません。

また、現在の仕事でReactiveCocoaとRexを使用しているので、できることなら何でも助けてくれることに興味があります。

参考までに、個人の遊び場https://github.com/inamiy/ReactiveCocoaCatalog/pull/8にRexデモを追加しました。
これまでのところ本当に素晴らしいコードであり、最初のステップとしてはorgに移行するだけで十分だと思います：sparkles：

これは、レックスをReactiveCocoaの公式の一部にするための素晴らしいアイデアです。 Swiftを使用すると、コードを複数のモジュールに分割するのが非常に簡単になり、メインモジュールのコア機能を維持し、UI固有の拡張機能に2番目のモジュールを導入することは間違いなく理にかなっています。

次の変更を提案します。

• Rexの名前を変更して、ReactiveCocoaの拡張機能であり、（ほとんど）UIに関するものであることを明確にします（@tonyarnoldによる）
• プレフィックスrex_xxxをrac_xxxに変更して、名前の一貫性を保ちます

@lukaskubanek私は最初の点に同意しますが、私は以下についてさまざまな意見を持っています：

プレフィックスrex_xxxをrac_xxxに変更して、名前の一貫性を保ちます

名前の一貫性は保たれますが、名前が異なるIMHOには、いくつかの利点があります。

1. 両方が必要になると仮定して、プロジェクトの最初に両方のライブラリを含めることができます。 最終的には、プロジェクトが進展するにつれて、Rexの演算子の使用をやめる可能性があります。 プロジェクトでrex_をすばやく検索すると、それを確認して依存関係として削除するのに役立ちます。
2. 1人のオペレーターに奇妙な振る舞いがあった場合、どのプロジェクトで問題を開くか（質問またはバグ）がすぐにわかります。
3. これは、初心者がどれがコアオペレーターであり、他のすべてがどこから構築されているかを理解するのに役立ちます。

コアSwiftコード、Obj-Cコード、およびSwift <-> Obj-Cブリッジを別々のリポジトリ（＃2807）に移動し、このリポジトリをCocoaバインディング用に残すことについて説明しました…したがって、Rexを移動する必要があると思いますこのリポジトリにRAC5としてコーディングします。

@neilpa @NachoSotoどう思いますか？

RexとSwiftのバインディングのReactiveCocoaObjCAPIへの依存は、分離中に削除されますか？つまり、Swiftで再実装されますか？ そうしないと、SwiftユーザーはいくつかのブリッジされたメソッドのためにObjCライブラリ全体を構築する必要があるため、分割IMOはメンテナンス以外では実際には効果的ではありません。

RexとSwiftのバインディングのReactiveCocoaObjCAPIへの依存は、分離中に削除されますか？つまり、Swiftで再実装されますか？

はい！ それは確かにいくつかのObjective-Cを含みますが、ReactiveObjCは含みません。

したがって、RexコードをRAC5としてこのリポジトリに移動する必要があると思います。

同意しましたが、リポジトリの履歴に注意する必要があります。 健全なレポ履歴を維持する移動/リベース/分割を管理する計画を立てる必要があります。

潜在的なsubtree splitオプションがない未解決の問題にも影響があります。

＃3210のおかげで、これは今行われていると思います。