Folder structure for RxCocoaExt addition

[freak4pc]

Description

This ticket continues discussion on one of the point form #127.

Would appreciate some opinions on what you guys would consider optimal Folder Structure and file-naming for RxSwift and RxCocoa related additions, at your spare time :)

Copying from the "Big issue":

Suggest folder structure for all components (Source/RxCocoa is great, but do we want more internal folders to separate ControlEvents, Operators, etc?)

Something like this might work (just a suggestion of course needs more discussion)

• RxSwift
  - Operators
  - Common (or Core or Observables or something to describe non-operators)
• RxCocoa
  - Operators
  - ControlEvents (or UI, or Components or something to describe non-operators related

Any opinions would be welcomed so I can move forward on this change :)

Thanks
Shai

[fpillet]

Separating the Operators from Common might not work for all cases. Some operators also have a static variant (like the and and cascade operators which provide both static and instance methods).

If we were to move each to separate folders, I'm not sure it would help making a mental image of the various functionalities exposed by RxSwiftExt.

It seems difficult to design a one-size-fits-all rule for this. There are other examples in the framework where naming is odd, like materialize+Elements.swift which was named like this to avoid conflicts with same file name in RxSwift, while providing another operator (errors()) which is not advertised by the actual file name. Also, flatMapSync and filterMap encompass several types of their own, which is another friction point (since they are public).

My take on this would be to:

• Keep master folders RxSwiftExt and RxCocoaExt
• Break materialized+elements.swift which could be split in
  • materialize+elements.swift
  • materiazlize+errors.swift
• Review what to do with ObservableType+Weak.swift which has several issues of its own:
  • poor naming of the subscribe methods (I would prefer names that don't overlap those in RxSwift)
  • odd naming of the file itself
  • also lacks proper examples of use, that's another topic we should address

[freak4pc]

@fpillet Good thoughts, thanks :)

My thought of separating was mainly in favor of RxCocoaExt - where operators and UI-related additions are entirely different and I feel like those shouldn't live in a single folder

For RxSwift I sort of agree most things could live in a single folder - Even though, extensions that have static methods are still operators; in RxSwift there isn't really much of a non-operator concept, so this is more related to RxCocoa as said earlier.

I'm not sure if we need a different file for each of these materialize operators... I think that could get a bit hairy, even though they are different operators so that should actually be fine. Does it mean the RxCocoa variants (if would exist) would be called materialize+elements+RxCocoa.swift? A bit of a mouthful.

ObservableType+Weak is its own issue to take care of, I agree :) Still need to think about it, but for now it can live inside the RxSwift folder as usual.

So I think the folder structure I currently have in mind is

• RxSwift
• RxCocoa
  • Operators
  • ControlEvents (or UI, or something that describes all non-UI things)

I don't think the "Ext" on each folder is needed as the project itself is already RxSwiftExt, and the folders just indicate what each folder "Extends".

RxSwift follows an even more convoluted folder structure but I don't think that's at all required for the purposes of this repo: https://github.com/ReactiveX/RxSwift/tree/master/RxCocoa

[fpillet]

Then why not:

• RxSwift
• RxCocoa
  • Common
  • UIKit
  • AppKit

This was we can put stuff like ControlEvents in Common and platform-specific ones in their respective folders.

[freak4pc]

That's cool actually!
The only problem with this is that components that have platform agnostic controls such as

typealias OSControl = UIButton vs typealias OSControl = NSButton variation would have to be split out in the two folders and I'm not entirely sure that's possible

Or those would be in "Common" ? Because that would mean we have Operators and Multi-platform UI living in a single folder, which beats the reasoning of trying to separate logically (unless you have UIKit, AppKit, Common and Operators or Core)