Reactivecocoa: Umzug von Rex in die ReactiveCocoa-Organisation

Ich bin dafür, Rex zur ReactiveCocoa-Organisation zu verschieben. Es begann als persönlicher Spielplatz, verwandelte sich aber in etwas Nützlicheres. Ich verwende RAC auch nicht mehr in meiner täglichen Arbeit, daher ist es sinnvoll, der Community die Verantwortung zu übertragen.

Bevor ich abdrücke, würde ich gerne wissen, wie @NachoSoto und @mdiep darüber denken.

Ich wäre voll dabei. Ich würde vorschlagen, einen Pass / Quick Code-Review durchzuführen (ich mache das gerne), um sicherzustellen, dass die Operatoren/Implementierungen dem Standard entsprechen (ich zweifle nicht daran). eine einzige Sekunde, wenn ich @neilpa kenne :)), aber nur um sicherzugehen, dass wir:

• wissen, welche Operatoren wir pflegen müssen (möglicherweise einige entfernen? idk).
• Stellen Sie sicher, dass wir Verbesserungsbereiche und offene Probleme identifizieren.

Wenn es das Ziel ist, die Bibliothek zugänglicher zu machen, würde ich vorschlagen, dass ein formellerer Name dabei helfen könnte. "Rex" erinnert mich nicht an ReactiveCocoa, wenn ich es sehe. Ich bin mir nicht sicher, was der richtige Name ist, aber etwas mit "ReactiveCocoa" oder sogar nur "Reactive" im Namen wäre meiner Meinung nach besser.

Ich habe mir Rex nicht wirklich angesehen, aber ich mag die Idee einer UI-fokussierten Bibliothek unter der ReactiveCocoa-Organisation. Rex scheint ein guter Anfang dafür zu sein. 👍 Ich denke, es ist auch eine großartige Idee, @NachoSoto einen Blick darauf werfen zu lassen.

Ich denke, wir müssen allgemein mehr Mitwirkende für RAC finden. Es scheint, als ob alle ziemlich dünn verteilt wurden.

@tonyarnold das könnte helfen. ✨

@mdiep Ich stimme zu. Dennoch braucht Rex noch etwas Arbeit in Sachen Dokumentation (README). Erstellen Sie vielleicht einen Katalog, damit die Leute wissen, welche Art von UI-Bindungen er bietet, anstatt den Quellcode überprüfen zu müssen. Dazu kommen natürlich noch die diversen Operatoren, die ebenfalls dokumentiert werden sollten.

Ich denke, wir müssen allgemein mehr Mitwirkende für RAC finden. Es scheint, als ob alle ziemlich dünn verteilt wurden.

Dem stimme ich auch zu, hier gibt es einiges zu tun:

1. Überarbeiten Sie die offenen Punkte .
2. Fügen Sie vielleicht weitere Anwendungsbeispiele hinzu , wie es hier gemacht wurde, und haben Sie ein Dokument dafür. Ich habe das mit RACNest versucht, aber statt mit Codeschnipseln mit einem interaktiven Projekt.
3. Schließen oder aktualisieren Sie einige der aufgegebenen Projekte (wie dieses , dieses und dieses ). Vielleicht könnte @jspahrsummers seine POV zu diesen Projekten mit uns teilen.
4. Fangen Sie möglicherweise an, sich auf den neuesten Stand zu bringen und etwas Ähnliches zu tun, was RxSwift hier getan hat (z. B. könnten wir Bindungen für Dinge wie Alamofire erstellen ). Dies mag eine beträchtliche Menge an Arbeit bedeuten, aber es wird auch neue Leute für das Framework gewinnen (ich denke, das ist einer der Gründe, warum RxSwift immer beliebter wird).

Ich helfe gerne dort, wo es nötig ist, da ich Rex und ReactiveCocoa in meinem aktuellen Job verwende.

@RuiAAPeres hat enorme Anstrengungen unternommen, um ReactiveCocoa und Rex zu verwenden und zu fördern. Ich denke, er kann ein guter Kernbeitrag sein. Ich denke, es gibt noch viel zu tun, um die aktuellen Bindungen zu modernisieren, aber auch neue bereitzustellen, und er könnte ein guter Gewinn sein, um dies zu erreichen.

Ich verwende ReactiveCocoa und Rex auch in meinem aktuellen Job, also bin ich auch verfügbar und an Hilfe interessiert, wo immer ich kann.

Zu Ihrer Information, ich habe die Rex-Demo in meinem persönlichen Playground https://github.com/inamiy/ReactiveCocoaCatalog/pull/8 hinzugefügt.
Bisher wirklich schöner Code, und ich denke, die Migration zu org reicht für den ersten Schritt aus :sparkles:

Das ist eine großartige Idee, Rex zu einem offiziellen Teil von ReactiveCocoa zu machen. Da Swift es wirklich einfach macht, Code in mehrere Module aufzuteilen, ist es auf jeden Fall sinnvoll, die Kernfunktionalität im Hauptmodul beizubehalten und ein zweites Modul für die UI-spezifischen Erweiterungen einzuführen.

Folgende Änderungen würde ich vorschlagen:

• Umbenennung von Rex, um deutlich zu machen, dass es sich um eine Erweiterung von ReactiveCocoa handelt und es (hauptsächlich) um die Benutzeroberfläche geht (wie von @tonyarnold angegeben)
• Ändern des Präfixes rex_xxx in rac_xxx , um die Benennung konsistent zu machen

@lukaskubanek Ich stimme dem ersten Punkt zu, aber ich habe gemischte Meinungen zu:

Ändern des Präfixes rex_xxx in rac_xxx, um die Benennung konsistent zu machen

Obwohl es die Benennung konsistent halten würde, hat es meiner Meinung nach mehrere Vorteile, es mit unterschiedlichen Namen zu haben:

1. Ich könnte beide Bibliotheken zu Beginn eines Projekts einschließen, vorausgesetzt, ich würde beide benötigen. Irgendwann, wenn sich das Projekt weiterentwickelt, werde ich vielleicht aufhören, einen der Operatoren von Rex zu verwenden. Eine schnelle Suche im Projekt nach rex_ würde mir helfen, dies zu bestätigen und es als Abhängigkeit zu entfernen.
2. Wenn bei einem Operator ein seltsames Verhalten auftritt, weiß ich sofort, in welchem ​​Projekt ich das Problem öffnen muss (eine Frage oder ein Fehler).
3. Es hilft Anfängern zu verstehen, welche die Kernoperatoren sind und worauf alle anderen aufbauen.

Wir haben darüber gesprochen, den Swift-Kerncode, den Obj-C-Code und die Swift <-> Obj-C-Brücke in separate Repos (#2807) zu verschieben und dieses Repo für die Cocoa-Bindungen zu belassen … Also denke ich, wir sollten den Rex verschieben Code in dieses Repository als RAC 5.

@neilpa @NachoSoto Was denkst du?

Würde die Abhängigkeit von Rex- und Swift-Anbindungen an die ReactiveCocoa ObjC-APIs während der Trennung entfernt, dh in Swift neu implementiert? Ansonsten wäre die Split-IMO in anderen Dingen als der Wartung nicht wirklich effektiv, da Swift-Benutzer immer noch die gesamte ObjC-Bibliothek für nur wenige Bridged-Methoden erstellen müssen.

Würde die Abhängigkeit von Rex- und Swift-Anbindungen an die ReactiveCocoa ObjC-APIs während der Trennung entfernt, dh in Swift neu implementiert?

Jawohl! Es würde definitiv etwas Objective-C beinhalten, aber nicht ReactiveObjC.

Ich denke also, wir sollten den Rex-Code als RAC 5 in dieses Repository verschieben.

Einverstanden, aber wir müssen bei der Repo-Historie vorsichtig sein. Wir sollten einen Plan entwickeln, um die Verschiebung/Rebase/Split zu verwalten, der eine vernünftige Repo-Historie aufrechterhält.

Es gibt auch Auswirkungen auf offene Probleme, für die wir nicht die potenzielle Option subtree split haben.

Ich nehme an, das ist jetzt dank #3210 erledigt!