Reactivecocoa: Memindahkan Rex ke org ReactiveCocoa

Saya mendukung pemindahan Rex ke org ReactiveCocoa. Ini dimulai sebagai taman bermain pribadi tetapi berubah menjadi sesuatu yang lebih berguna. Saya juga tidak menggunakan RAC dalam pekerjaan sehari-hari saya lagi sehingga memberikan kepemilikan kepada komunitas masuk akal.

Sebelum menarik pelatuk, saya ingin tahu bagaimana perasaan @NachoSoto dan @mdiep tentang hal itu.

Saya akan benar-benar terlibat. Saya sarankan melakukan tinjauan kode lulus/cepat (saya senang melakukannya) untuk memastikan bahwa operator/implementasi sesuai standar (saya tidak meragukannya untuk satu detik mengetahui @neilpa :)), tetapi hanya untuk memastikan kami:

• mengetahui operator mana yang perlu kita pertahankan (mungkin menghapus beberapa? idk).
• pastikan kami mengidentifikasi area perbaikan dan masalah terbuka.

Jika membuat perpustakaan lebih mudah diakses adalah tujuannya, saya sarankan nama yang lebih formal dapat membantu dengan itu. "Rex" tidak mengingat ReactiveCocoa ketika saya melihatnya. Tidak yakin apa nama yang tepat, tetapi sesuatu dengan "ReactiveCocoa" atau bahkan hanya "Reactive" di namanya akan lebih baik IMO.

Saya belum benar-benar melihat Rex, tetapi saya menyukai gagasan perpustakaan yang berfokus pada UI di bawah org ReactiveCocoa. Rex sepertinya awal yang baik untuk itu. 👍 Saya pikir meminta @NachoSoto untuk melihatnya terlebih dahulu adalah ide yang bagus juga.

Saya pikir kita perlu menemukan lebih banyak kontributor inti untuk RAC secara umum. Sepertinya semua orang telah menyebar cukup tipis.

@tonyarnold yang bisa membantu. ✨.

@mdiep saya setuju. Namun, Rex membutuhkan sedikit pekerjaan dalam hal dokumentasi (README). Mungkin membuat katalog sehingga orang tahu jenis ikatan UI apa yang disediakannya, daripada harus memeriksa kode sumbernya. Ada juga operator lain-lain, yang juga harus didokumentasikan.

Saya pikir kita perlu menemukan lebih banyak kontributor inti untuk RAC secara umum. Sepertinya semua orang telah menyebar cukup tipis.

Saya setuju dengan ini juga, ada sedikit pekerjaan yang harus dilakukan di sini:

1. Merevisi isu- isu terbuka .
2. Mungkin menambahkan contoh penggunaan lebih lanjut , seperti yang dilakukan di sini dan memiliki dokumen untuk itu. Saya telah mencobanya dengan RACNest , tetapi, alih-alih potongan kode, dengan proyek interaktif.
3. Tutup atau perbarui beberapa proyek yang ditinggalkan (seperti this , this dan this ). Mungkin @jspahrsummers dapat berbagi dengan kami POV-nya tentang proyek-proyek ini.
4. Berpotensi mulai mempercepat dan melakukan sesuatu yang mirip dengan apa yang dilakukan RxSwift di sini (misalnya kita dapat membuat ikatan untuk hal-hal seperti Alamofire ). Ini mungkin pekerjaan yang cukup banyak, tetapi juga akan menarik orang baru ke kerangka kerja (saya pikir ini adalah salah satu alasan mengapa RxSwift semakin populer).

Saya senang membantu jika diperlukan, karena saya menggunakan Rex dan ReactiveCocoa pada pekerjaan saya saat ini.

@RuiAAPeres telah berusaha keras dalam menggunakan dan mempromosikan ReactiveCocoa dan Rex, saya pikir dia bisa menjadi kontributor inti yang baik. Saya pikir masih banyak pekerjaan yang harus dilakukan untuk memodernisasi binding saat ini tetapi juga menyediakan yang baru dan dia mungkin merupakan aset yang baik untuk mencapainya.

Saya juga menggunakan ReactiveCocoa dan Rex pada pekerjaan saya saat ini, jadi saya juga tersedia dan tertarik untuk membantu dalam segala hal yang saya bisa.

FYI, saya menambahkan demo Rex di taman bermain pribadi saya https://github.com/inamiy/ReactiveCocoaCatalog/pull/8.
Kode yang sangat bagus sejauh ini, dan saya pikir hanya bermigrasi ke org sudah cukup untuk langkah pertama :sparkles:

Itu ide bagus untuk menjadikan Rex bagian resmi dari ReactiveCocoa. Karena Swift membuatnya sangat mudah untuk membagi kode menjadi beberapa modul dengan menjaga fungsionalitas inti di modul utama dan memperkenalkan modul kedua untuk ekstensi khusus UI pasti masuk akal.

Saya akan mengusulkan perubahan berikut:

• Mengganti nama Rex untuk memperjelas bahwa itu adalah ekstensi untuk ReactiveCocoa dan (kebanyakan) tentang UI (seperti yang dinyatakan oleh @tonyarnold)
• Mengubah awalan rex_xxx menjadi rac_xxx untuk membuat penamaan konsisten

@lukaskubanek Saya setuju dengan poin pertama, tetapi saya memiliki pendapat yang beragam tentang:

Mengubah awalan rex_xxx menjadi rac_xxx untuk membuat penamaan konsisten

Meskipun penamaan akan tetap konsisten, memilikinya dengan nama yang berbeda, IMHO, memiliki beberapa keuntungan:

1. Saya mungkin memasukkan kedua lib di awal proyek dengan asumsi saya membutuhkan keduanya. Akhirnya, seiring perkembangan proyek, saya mungkin berhenti menggunakan salah satu operator Rex. Pencarian cepat dalam proyek untuk rex_ akan membantu saya mengonfirmasi itu dan menghapusnya sebagai ketergantungan.
2. Jika ada perilaku aneh di satu operator, saya langsung tahu di proyek mana untuk membuka masalah (menjadi pertanyaan, atau bug).
3. Ini membantu pemula memahami mana yang merupakan operator inti, dari mana semua yang lain dibangun.

Kita telah mendiskusikan pemindahan kode inti Swift, kode Obj-C, dan jembatan Swift <-> Obj-C ke dalam repo terpisah (#2807), meninggalkan repo ini untuk ikatan Kakao… Jadi saya pikir kita harus memindahkan Rex kode ke dalam repositori ini sebagai RAC 5.

@neilpa @NachoSoto Bagaimana menurutmu?

Apakah ketergantungan binding Rex dan Swift pada ReactiveCocoa ObjC API akan dihapus selama pemisahan, yaitu diimplementasikan kembali di Swift? Jika tidak, IMO split tidak akan benar-benar efektif dalam hal-hal selain pemeliharaan, karena pengguna Swift masih perlu membangun seluruh perpustakaan ObjC hanya untuk beberapa metode yang dijembatani.

Apakah ketergantungan binding Rex dan Swift pada ReactiveCocoa ObjC API akan dihapus selama pemisahan, yaitu diimplementasikan kembali di Swift?

Ya! Itu pasti akan melibatkan beberapa Objective-C, tetapi tidak akan melibatkan ReactiveObjC.

Jadi saya pikir kita harus memindahkan kode Rex ke dalam repositori ini sebagai RAC 5.

Setuju, tetapi kita harus berhati-hati dengan riwayat repo. Kita harus menerapkan rencana untuk mengelola pemindahan/rebase/split yang mempertahankan riwayat repo yang waras.

Ada juga konsekuensi untuk masalah terbuka yang tidak memiliki opsi subtree split potensial.

Saya kira ini sudah selesai sekarang, terima kasih kepada #3210!