Reactivecocoa: Moving Rex to the ReactiveCocoa org

I'm in favor of moving Rex over to the ReactiveCocoa org. It started as a personal playground but morphed into something more useful. I also don't use RAC in my day job anymore so giving ownership to the community makes sense.

Before pulling the trigger I'd like to know how @NachoSoto and @mdiep feel about it.

I'd be totally in. I'd suggest doing a pass / quick code-review (I'm happy to do it) to make sure that the operators/implementations are up-to-standard (I don't doubt it for a single second knowing @neilpa though :)), but just to make sure we:

• are aware of which operators we'll need to maintain (possibly removing some? idk).
• make sure we identify areas of improvement and open issues.

If making the library more accessible is the goal, I'd suggest a more formal name might help with that. "Rex" doesn't bring ReactiveCocoa to mind when I see it. Not sure what the right name is, but something with "ReactiveCocoa" or even just "Reactive" in the name would be better IMO.

I haven't really looked at Rex, but I like the idea of a UI-focused library under the ReactiveCocoa org. Rex seems like a good start to that. 👍 I think having @NachoSoto give it a look first is a great idea too.

I do think we need to find some more core contributors for RAC in general. It seems like everyone has been spread pretty thin.

@tonyarnold that could help. ✨

@mdiep I agree. Still, Rex needs a bit of work in terms of documentation (README). Maybe create a catalogue so people know what kind of UI binds it provides, instead of having to check the source code. There is also of course the miscellaneous operators, that should be also documented.

I do think we need to find some more core contributors for RAC in general. It seems like everyone has been spread pretty thin.

I agree with this as well, there is a fair bit of work to be done here:

1. Revise the open issues.
2. Maybe add further examples of usage, like it was done here and have a document for that. I have tried to that with RACNest, but, instead of snippets of code, with a interactive project.
3. Close or update some of the abandoned projects (like this, this and this). Maybe @jspahrsummers could share with us his POV on these projects.
4. Potentially start getting up to speed and do something similar to what RxSwift did here (e.g. we could create binds for things like Alamofire). This might be a considerable amount of work, but it will also attract new people to the framework (I think this is one of the reasons why RxSwift has been rising in popularity).

I am happy to help where it is needed, since I am using Rex and ReactiveCocoa on my current job.

@RuiAAPeres has put a tremendous effort in using and promoting ReactiveCocoa and Rex, I think he can be a good core contributor. I think there's still a lot of work to do to modernize the current bindings but also provide new ones and he may be a good asset to achieve that.

I'm also using ReactiveCocoa and Rex on my current job so I'm also available and interested in help in anything that I can.

FYI, I added Rex demo in my personal playground https://github.com/inamiy/ReactiveCocoaCatalog/pull/8.
Really nice code so far, and I think just migrating to org is enough for the first step :sparkles:

That’s a great idea to make Rex an official part of ReactiveCocoa. Since Swift makes it really easy to split code into multiple modules keeping the core functionality in the main module and introducing a second module for the UI-specific extensions definitely makes sense.

I would propose following changes:

• Renaming Rex to make obvious that it's an extension to ReactiveCocoa and it's (mostly) about UI (as stated by @tonyarnold)
• Changing the prefix rex_xxx to rac_xxx to make the naming consistent

@lukaskubanek I agree with the first point, but I have mixed opinions about:

Changing the prefix rex_xxx to rac_xxx to make the naming consistent

Although it would keep naming consistent, having it with different names, IMHO, has several advantages:

1. I might include both libs in the beginning of a project assuming I would need both of them. Eventually, as the project evolves, I might stop using any of Rex's operators. A quick search in the project for rex_ would help me confirming that and remove it as a dependency.
2. If there is a weird behaviour in one operator, I know immediately in which project to open the issue (being a question, or bug).
3. It helps beginners understanding which ones are the core operators, from where all the others are built upon.

We've discussed moving the core Swift code, the Obj-C code, and the Swift <-> Obj-C bridge into separate repos (#2807), leaving this repo for the Cocoa bindings… So I think we should move the Rex code into this repository as RAC 5.

@neilpa @NachoSoto What do you think?

Would the dependency of Rex and Swift bindings on the ReactiveCocoa ObjC APIs be removed during the separation, i.e. reimplemented in Swift? Otherwise, the split IMO would not be really effective in things other than the maintenance, since Swift users still need to build the entire ObjC library for just a few bridged methods.

Would the dependency of Rex and Swift bindings on the ReactiveCocoa ObjC APIs be removed during the separation, i.e. reimplemented in Swift?

Yes! It would definitely involve some Objective-C, but would not involve ReactiveObjC.

So I think we should move the Rex code into this repository as RAC 5.

Agreed, but we'll need to be careful about repo history. We should oultine a plan to manage the move/rebase/split that maintains a sane repo history.

There's also ramifications for open issues which we don't have the potential subtree split option.

I suppose this is done now, thanks to #3210!