Reactivecocoa: ReactiveCocoa 조직으로 Rex 이동

Rex를 ReactiveCocoa 조직으로 옮기는 것에 찬성합니다. 개인 놀이터로 시작했지만 더 유용한 것으로 변모했습니다. 또한 더 이상 일상 업무에서 RAC를 사용하지 않으므로 커뮤니티에 소유권을 부여하는 것이 합리적입니다.

방아쇠를 당기기 전에 @NachoSoto 와 @mdiep 이 그것에 대해 어떻게 느끼는지 알고 싶습니다.

나는 완전히 참여할 것입니다. 나는 연산자/구현이 표준에 부합하는지 확인하기 위해 통과/빠른 코드 검토를 제안할 것입니다(나는 기쁘게 생각합니다). @neilpa 를 아는 1초 :)), 하지만 다음을 확인하기 위해:

• 어떤 연산자를 유지 관리해야 하는지 알고 있습니다(일부 제거 가능? idk).
• 개선 영역과 미해결 문제가 있는지 확인합니다.

라이브러리를 더 쉽게 액세스할 수 있도록 하는 것이 목표라면 좀 더 공식적인 이름이 도움이 될 수 있다고 제안합니다. "Rex"는 내가 볼 때 ReactiveCocoa를 떠올리게 하지 않습니다. 올바른 이름이 무엇인지 확실하지 않지만 이름에 "ReactiveCocoa" 또는 "Reactive"만 있는 것이 더 나은 IMO입니다.

Rex를 실제로 본 적은 없지만 ReactiveCocoa org에서 UI 중심 라이브러리라는 아이디어가 마음에 듭니다. 렉스는 좋은 출발인 것 같습니다. 👍 @NachoSoto를 먼저 보시는 것도 좋은 아이디어인 것 같아요.

일반적으로 RAC에 대한 핵심 기여자를 더 찾아야 한다고 생각합니다. 모두가 꽤 얇게 퍼진 것 같습니다.

@tonyarnold 도움이 될 수 있습니다. ✨

@mdiep 동의합니다. 그래도 Rex는 문서(README) 측면에서 약간의 작업이 필요합니다. 소스 코드를 확인하는 대신 카탈로그가 제공하는 UI 바인딩의 종류를 사람들이 알 수 있도록 카탈로그를 생성할 수 있습니다. 물론 문서화해야 하는 기타 연산자도 있습니다.

일반적으로 RAC에 대한 핵심 기여자를 더 찾아야 한다고 생각합니다. 모두가 꽤 얇게 퍼진 것 같습니다.

저도 여기에 동의합니다. 여기서 해야 할 일이 꽤 있습니다.

1. 미해결 문제 를 수정합니다.
2. 여기 에서 수행한 것처럼 사용 예를 더 추가 하고 이에 대한 문서를 가지고 있습니다. RACNest 를 사용하여 시도했지만 코드 조각 대신 대화형 프로젝트를 사용했습니다.
3. 일부 중단된 프로젝트( this , this 및 this )를 닫거나 업데이트합니다. 어쩌면 @jspahrsummers 가 이 프로젝트에 대한 그의 POV를 우리와 공유할 수 있습니다.
4. 잠재적으로 속도를 높이고 여기에서 RxSwift가 수행한 것과 유사한 작업을 수행하십시오(예: Alamofire 와 같은 것에 대한 바인드를 생성할 수 있음). 이것은 상당한 작업량일 수 있지만 프레임워크에 새로운 사람들을 끌어들이기도 합니다(이것이 RxSwift가 인기를 얻고 있는 이유 중 하나라고 생각합니다).

현재 직장에서 Rex와 ReactiveCocoa를 사용하고 있기 때문에 필요한 곳에 도움을 드릴 수 있어 기쁩니다.

@RuiAAPeres 는 ReactiveCocoa와 Rex를 사용하고 홍보하는 데 엄청난 노력을 기울였습니다. 저는 그가 좋은 핵심 기여자가 될 수 있다고 생각합니다. 현재 바인딩을 현대화하고 새로운 바인딩을 제공하기 위해 아직 해야 할 일이 많이 있으며 이를 달성하는 데 좋은 자산이 될 수 있다고 생각합니다.

나는 또한 현재 직장에서 ReactiveCocoa와 Rex를 사용하고 있으므로 내가 할 수 있는 모든 도움을 받을 수 있고 관심이 있습니다.

참고로 개인 놀이터 https://github.com/inamiy/ReactiveCocoaCatalog/pull/8에 Rex 데모를 추가했습니다.
지금까지는 정말 좋은 코드입니다. 첫 번째 단계는 org로 마이그레이션하는 것만으로도 충분하다고 생각합니다.

Rex를 ReactiveCocoa의 공식 일부로 만드는 것은 좋은 생각입니다. Swift를 사용하면 코드를 여러 모듈로 쉽게 분할할 수 있으므로 기본 모듈의 핵심 기능을 유지하고 UI별 확장을 위한 두 번째 모듈을 도입하는 것이 확실히 의미가 있습니다.

다음 변경 사항을 제안합니다.

• ReactiveCocoa의 확장이며 (대부분) UI에 관한 것임을 분명히 하기 위해 Rex의 이름을 바꿉니다(@tonyarnold가 언급함).
• 이름을 일관성 있게 만들기 위해 접두사 rex_xxx 를 rac_xxx 로 변경

@lukaskubanek 나는 첫 번째 요점에 동의하지만 다음에 대해 의견이 엇갈립니다.

이름을 일관성 있게 만들기 위해 접두사 rex_xxx를 rac_xxx로 변경

이름을 일관되게 유지하지만 IMHO를 다른 이름으로 사용하면 다음과 같은 몇 가지 이점이 있습니다.

1. 두 라이브러리가 모두 필요하다고 가정하면 프로젝트 시작 시 두 라이브러리를 모두 포함할 수 있습니다. 결국 프로젝트가 진행됨에 따라 Rex의 오퍼레이터 사용을 중단할 수도 있습니다. 프로젝트에서 rex_ 를 빠르게 검색하면 이를 확인하고 종속성으로 제거하는 데 도움이 됩니다.
2. 한 운영자에게 이상한 동작이 있는 경우 문제(질문 또는 버그)를 여는 프로젝트를 즉시 알 수 있습니다.
3. 초보자가 핵심 연산자가 무엇인지 이해하는 데 도움이 됩니다.

핵심 Swift 코드, Obj-C 코드 및 Swift <-> Obj-C 브리지를 별도의 repos(#2807)로 옮기고 Cocoa 바인딩을 위해 이 repo를 남겨두는 것에 대해 논의했습니다. 그래서 Rex를 옮겨야 한다고 생각합니다. 이 리포지토리에 RAC 5로 코드를 입력합니다.

@neilpa @NachoSoto 어떻게 생각하세요?

ReactiveCocoa ObjC API에 대한 Rex 및 Swift 바인딩의 종속성이 분리 중에 제거됩니까? 즉, Swift에서 다시 구현됩니까? 그렇지 않으면 Swift 사용자는 여전히 몇 가지 브리지 방법에 대해 전체 ObjC 라이브러리를 빌드해야 하기 때문에 분할 IMO는 유지 관리 이외의 작업에서는 실제로 효과적이지 않습니다.

ReactiveCocoa ObjC API에 대한 Rex 및 Swift 바인딩의 종속성이 분리 중에 제거됩니까? 즉, Swift에서 다시 구현됩니까?

네! 그것은 분명히 일부 Objective-C를 포함하지만 ReactiveObjC는 포함하지 않을 것입니다.

그래서 Rex 코드를 RAC 5로 이 저장소로 옮겨야 한다고 생각합니다.

동의하지만 repo 기록에 대해 주의해야 합니다. 정상적인 repo 기록을 유지하는 이동/리베이스/분할을 관리하기 위한 계획을 수립해야 합니다.

잠재적인 subtree split 옵션이 없는 미해결 문제에 대한 결과도 있습니다.

#3210 덕분에 이제 끝난 것 같아요!