Reactivecocoa: Déplacement de Rex vers l'organisation ReactiveCocoa

Je suis en faveur du transfert de Rex vers l'organisation ReactiveCocoa. Cela a commencé comme un terrain de jeu personnel, mais s'est transformé en quelque chose de plus utile. De plus, je n'utilise plus RAC dans mon travail quotidien, il est donc logique de donner la propriété à la communauté.

Avant d'appuyer sur la gâchette, j'aimerais savoir ce que pensent @NachoSoto et @mdiep .

Je serais totalement dedans. Je suggérerais de faire une passe / une révision rapide du code (je suis heureux de le faire) pour m'assurer que les opérateurs / implémentations sont à la hauteur (je n'en doute pas pour une seule seconde connaissant @neilpa cependant :)), mais juste pour être sûr que nous :

• savent quels opérateurs nous devrons maintenir (éventuellement en supprimer certains ? idk).
• assurez-vous que nous identifions les domaines d'amélioration et les problèmes ouverts.

Si l'objectif est de rendre la bibliothèque plus accessible, je suggérerais qu'un nom plus formel pourrait aider à cela. "Rex" ne me rappelle pas ReactiveCocoa quand je le vois. Je ne sais pas quel est le bon nom, mais quelque chose avec "ReactiveCocoa" ou même simplement "Reactive" dans le nom serait mieux IMO.

Je n'ai pas vraiment regardé Rex, mais j'aime l'idée d'une bibliothèque axée sur l'interface utilisateur sous l'organisation ReactiveCocoa. Rex semble être un bon début pour ça. 👍 Je pense que demander à @NachoSoto d'y jeter un coup d'œil est également une excellente idée.

Je pense que nous devons trouver d'autres contributeurs principaux pour RAC en général. Il semble que tout le monde a été assez dispersé.

@tonyarnold qui pourrait aider. ✨

@mdiep Je suis d'accord. Pourtant, Rex a besoin d'un peu de travail en termes de documentation (README). Créez peut-être un catalogue pour que les gens sachent quel type d'interface utilisateur il fournit, au lieu d'avoir à vérifier le code source. Il y a aussi bien sûr les opérateurs divers, qui doivent également être documentés.

Je pense que nous devons trouver d'autres contributeurs principaux pour RAC en général. Il semble que tout le monde a été assez dispersé.

Je suis également d'accord avec cela, il y a pas mal de travail à faire ici:

1. Révisez les questions ouvertes .
2. Ajoutez peut-être d'autres exemples d'utilisation , comme cela a été fait ici et ayez un document pour cela. J'ai essayé de le faire avec RACNest , mais, au lieu d'extraits de code, avec un projet interactif.
3. Fermez ou mettez à jour certains des projets abandonnés (comme this , this et this ). Peut-être que @jspahrsummers pourrait partager avec nous son point de vue sur ces projets.
4. Potentiellement, commencez à vous mettre au courant et faites quelque chose de similaire à ce que RxSwift a fait ici (par exemple, nous pourrions créer des liaisons pour des choses comme Alamofire ). Cela peut représenter une quantité de travail considérable, mais cela attirera également de nouvelles personnes dans le framework (je pense que c'est l'une des raisons pour lesquelles RxSwift gagne en popularité).

Je suis heureux d'aider là où c'est nécessaire, puisque j'utilise Rex et ReactiveCocoa dans mon travail actuel.

@RuiAAPeres a déployé des efforts considérables pour utiliser et promouvoir ReactiveCocoa et Rex, je pense qu'il peut être un bon contributeur principal. Je pense qu'il y a encore beaucoup de travail à faire pour moderniser les fixations actuelles mais aussi en proposer de nouvelles et il peut être un bon atout pour y parvenir.

J'utilise également ReactiveCocoa et Rex dans mon travail actuel, donc je suis également disponible et intéressé à aider dans tout ce que je peux.

Pour votre information, j'ai ajouté la démo Rex dans mon terrain de jeu personnel https://github.com/inamiy/ReactiveCocoaCatalog/pull/8.
Code vraiment sympa jusqu'à présent, et je pense que la migration vers org suffit pour la première étape :sparkles:

C'est une excellente idée de faire de Rex une partie officielle de ReactiveCocoa. Étant donné que Swift permet de diviser très facilement le code en plusieurs modules, il est tout à fait logique de conserver les fonctionnalités de base dans le module principal et d'introduire un deuxième module pour les extensions spécifiques à l'interface utilisateur.

Je proposerais les modifications suivantes :

• Renommer Rex pour rendre évident qu'il s'agit d'une extension de ReactiveCocoa et qu'il s'agit (principalement) d'interface utilisateur (comme indiqué par @tonyarnold)
• Changer le préfixe rex_xxx en rac_xxx pour rendre le nommage cohérent

@lukaskubanek Je suis d'accord avec le premier point, mais j'ai des opinions mitigées sur :

Changer le préfixe rex_xxx en rac_xxx pour rendre le nommage cohérent

Bien que la dénomination reste cohérente, l'avoir avec des noms différents, à mon humble avis, présente plusieurs avantages :

1. Je pourrais inclure les deux bibliothèques au début d'un projet en supposant que j'aurais besoin des deux. Finalement, au fur et à mesure que le projet évolue, je pourrais cesser d'utiliser l'un des opérateurs de Rex. Une recherche rapide dans le projet pour rex_ m'aiderait à le confirmer et à le supprimer en tant que dépendance.
2. S'il y a un comportement bizarre chez un opérateur, je sais immédiatement dans quel projet ouvrir le problème (qu'il s'agisse d'une question ou d'un bogue).
3. Cela aide les débutants à comprendre lesquels sont les opérateurs principaux, à partir desquels tous les autres sont construits.

Nous avons discuté du déplacement du code Swift principal, du code Obj-C et du pont Swift <-> Obj-C dans des dépôts séparés (# 2807), laissant ce dépôt pour les liaisons Cocoa… Je pense donc que nous devrions déplacer le Rex code dans ce référentiel en tant que RAC 5.

@neilpa @NachoSoto Qu'en pensez-vous ?

La dépendance des liaisons Rex et Swift sur les API ReactiveCocoa ObjC serait-elle supprimée lors de la séparation, c'est-à-dire réimplémentée dans Swift ? Sinon, la division IMO ne serait pas vraiment efficace dans d'autres domaines que la maintenance, car les utilisateurs de Swift doivent encore créer l'intégralité de la bibliothèque ObjC pour seulement quelques méthodes pontées.

La dépendance des liaisons Rex et Swift sur les API ReactiveCocoa ObjC serait-elle supprimée lors de la séparation, c'est-à-dire réimplémentée dans Swift ?

Oui! Cela impliquerait certainement un certain Objective-C, mais n'impliquerait pas ReactiveObjC.

Je pense donc que nous devrions déplacer le code Rex dans ce référentiel en tant que RAC 5.

D'accord, mais nous devrons faire attention à l'historique des dépôts. Nous devrions élaborer un plan pour gérer le déménagement/rebase/split qui maintient un historique de dépôt sain.

Il y a aussi des ramifications pour les problèmes ouverts pour lesquels nous n'avons pas l'option potentielle subtree split .

Je suppose que c'est chose faite maintenant, grâce au #3210 !