Reactivecocoa: Traslado de Rex a la organización ReactiveCocoa

Estoy a favor de trasladar a Rex a la organización ReactiveCocoa. Comenzó como un patio de recreo personal, pero se transformó en algo más útil. Tampoco uso RAC en mi trabajo diario, por lo que tiene sentido darle propiedad a la comunidad.

Antes de apretar el gatillo me gustaría saber cómo se sienten @NachoSoto y @mdiep al respecto.

Estaría totalmente dentro. Sugeriría hacer una revisión de código rápida / aprobada (estoy feliz de hacerlo) para asegurarme de que los operadores / implementaciones estén al día (no lo dudo por aunque un solo segundo conociendo a @neilpa :)), pero solo para asegurarnos de que:

• somos conscientes de qué operadores necesitaremos mantener (¿posiblemente eliminar algunos? idk).
• asegúrese de identificar áreas de mejora y problemas abiertos.

Si el objetivo es hacer que la biblioteca sea más accesible, sugeriría que un nombre más formal podría ayudar con eso. "Rex" no me recuerda a ReactiveCocoa cuando lo veo. No estoy seguro de cuál es el nombre correcto, pero algo con "ReactiveCocoa" o incluso simplemente "Reactivo" en el nombre sería mejor en mi opinión.

Realmente no he mirado a Rex, pero me gusta la idea de una biblioteca centrada en la interfaz de usuario en la organización ReactiveCocoa. Rex parece un buen comienzo para eso. 👍 Creo que tener a @NachoSoto dándole un vistazo primero también es una gran idea.

Creo que necesitamos encontrar más contribuyentes centrales para RAC en general. Parece que todo el mundo se ha dispersado bastante.

@tonyarnold que podría ayudar. ✨

@mdiep Estoy de acuerdo. Aún así, Rex necesita un poco de trabajo en términos de documentación (README). Tal vez cree un catálogo para que las personas sepan qué tipo de enlace de interfaz de usuario proporciona, en lugar de tener que verificar el código fuente. Por supuesto, también están los operadores misceláneos, que también deben documentarse.

Creo que necesitamos encontrar más contribuyentes centrales para RAC en general. Parece que todo el mundo se ha dispersado bastante.

Estoy de acuerdo con esto también, hay bastante trabajo por hacer aquí:

1. Revisar los temas abiertos .
2. Tal vez agregue más ejemplos de uso , como se hizo aquí y tenga un documento para eso. Lo he intentado con RACNest , pero, en lugar de fragmentos de código, con un proyecto interactivo.
3. Cierre o actualice algunos de los proyectos abandonados (como este , este y este ). Tal vez @jspahrsummers podría compartir con nosotros su punto de vista sobre estos proyectos.
4. Potencialmente, comience a ponerse al día y haga algo similar a lo que hizo RxSwift aquí (por ejemplo, podríamos crear enlaces para cosas como Alamofire ). Esto podría ser una cantidad considerable de trabajo, pero también atraerá a nuevas personas al marco (creo que esta es una de las razones por las que RxSwift ha ganado popularidad).

Estoy feliz de ayudar donde sea necesario, ya que estoy usando Rex y ReactiveCocoa en mi trabajo actual.

@RuiAAPeres ha puesto un gran esfuerzo en usar y promocionar ReactiveCocoa y Rex, creo que puede ser un buen colaborador principal. Creo que todavía queda mucho trabajo por hacer para modernizar las fijaciones actuales, pero también para proporcionar otras nuevas y él puede ser un buen activo para lograrlo.

También estoy usando ReactiveCocoa y Rex en mi trabajo actual, así que también estoy disponible e interesado en recibir ayuda en todo lo que pueda.

Para su información, agregué la demostración de Rex en mi área de juegos personal https://github.com/inamiy/ReactiveCocoaCatalog/pull/8.
Muy buen código hasta ahora, y creo que solo migrar a org es suficiente para el primer paso :sparkles:

Es una gran idea hacer de Rex una parte oficial de ReactiveCocoa. Dado que Swift hace que sea muy fácil dividir el código en varios módulos, manteniendo la funcionalidad central en el módulo principal e introduciendo un segundo módulo para las extensiones específicas de la interfaz de usuario, definitivamente tiene sentido.

Yo propondría los siguientes cambios:

• Cambiar el nombre de Rex para que sea obvio que es una extensión de ReactiveCocoa y se trata (principalmente) de la interfaz de usuario (según lo declarado por @tonyarnold)
• Cambiando el prefijo rex_xxx a rac_xxx para que el nombre sea consistente

@lukaskubanek Estoy de acuerdo con el primer punto, pero tengo opiniones encontradas sobre:

Cambiando el prefijo rex_xxx a rac_xxx para que el nombre sea consistente

Aunque mantendría la nomenclatura constante, tenerlo con diferentes nombres, en mi humilde opinión, tiene varias ventajas:

1. Podría incluir ambas bibliotecas al comienzo de un proyecto, suponiendo que las necesitaría a ambas. Eventualmente, a medida que el proyecto evolucione, podría dejar de usar cualquiera de los operadores de Rex. Una búsqueda rápida en el proyecto de rex_ me ayudaría a confirmar eso y eliminarlo como una dependencia.
2. Si hay un comportamiento extraño en un operador, sé de inmediato en qué proyecto abrir el problema (ya sea una pregunta o un error).
3. Ayuda a los principiantes a comprender cuáles son los operadores principales, desde donde se construyen todos los demás.

Hemos discutido mover el código Swift central, el código Obj-C y el puente Swift <-> Obj-C a repositorios separados (#2807), dejando este repositorio para los enlaces de Cocoa... Así que creo que deberíamos mover el Rex código en este repositorio como RAC 5.

@neilpa @NachoSoto ¿Qué opinas?

¿Se eliminaría la dependencia de los enlaces de Rex y Swift en las API de ReactiveCocoa ObjC durante la separación, es decir, se volvería a implementar en Swift? De lo contrario, la IMO dividida no sería realmente efectiva en otras cosas además del mantenimiento, ya que los usuarios de Swift aún necesitan compilar la biblioteca completa de ObjC solo para algunos métodos puenteados.

¿Se eliminaría la dependencia de los enlaces de Rex y Swift en las API de ReactiveCocoa ObjC durante la separación, es decir, se volvería a implementar en Swift?

¡Sí! Definitivamente involucraría algo de Objective-C, pero no involucraría ReactiveObjC.

Así que creo que deberíamos mover el código Rex a este repositorio como RAC 5.

De acuerdo, pero tendremos que tener cuidado con el historial de repositorios. Deberíamos diseñar un plan para administrar el movimiento/rebase/división que mantenga un historial de repositorios sensato.

También hay ramificaciones para problemas abiertos en los que no tenemos la opción potencial subtree split .

¡Supongo que esto ya está hecho, gracias a #3210!