Reactivecocoa: Movendo o Rex para a organização ReactiveCocoa

Sou a favor de transferir Rex para a organização ReactiveCocoa. Começou como um playground pessoal, mas se transformou em algo mais útil. Eu também não uso mais o RAC no meu trabalho diário, então dar propriedade à comunidade faz sentido.

Antes de puxar o gatilho, gostaria de saber como @NachoSoto e @mdiep se sentem sobre isso.

Eu estaria totalmente dentro. Eu sugiro fazer uma revisão rápida do código (estou feliz em fazê-lo) para ter certeza de que os operadores/implementações estão de acordo com o padrão (não duvido disso para um único segundo conhecendo @neilpa :)), mas apenas para ter certeza de que:

• estão cientes de quais operadores precisaremos manter (possivelmente removendo alguns? idk).
• certifique-se de identificar áreas de melhoria e questões em aberto.

Se tornar a biblioteca mais acessível é o objetivo, sugiro que um nome mais formal possa ajudar nisso. "Rex" não me lembra ReactiveCocoa quando o vejo. Não tenho certeza qual é o nome certo, mas algo com "ReactiveCocoa" ou mesmo apenas "Reactive" no nome seria melhor IMO.

Eu realmente não olhei para o Rex, mas gosto da ideia de uma biblioteca focada na interface do usuário na organização ReactiveCocoa. Rex parece ser um bom começo para isso. 👍 Acho que ter @NachoSoto dando uma olhada primeiro também é uma ótima ideia.

Acho que precisamos encontrar mais alguns colaboradores principais para o RAC em geral. Parece que todo mundo foi bem espalhado.

@tonyarnold que poderia ajudar. ✨

@mdiep concordo. Ainda assim, Rex precisa de um pouco de trabalho em termos de documentação (README). Talvez crie um catálogo para que as pessoas saibam que tipo de vinculação de interface do usuário ele fornece, em vez de ter que verificar o código-fonte. Há também os operadores diversos, que também devem ser documentados.

Acho que precisamos encontrar mais alguns colaboradores principais para o RAC em geral. Parece que todo mundo foi bem espalhado.

Concordo com isso também, há um pouco de trabalho a ser feito aqui:

1. Revise as questões em aberto .
2. Talvez adicionar mais exemplos de uso , como foi feito aqui e ter um documento para isso. Eu tentei isso com RACNest , mas, em vez de trechos de código, com um projeto interativo.
3. Feche ou atualize alguns dos projetos abandonados (como este , este e este ). Talvez @jspahrsummers possa compartilhar conosco seu ponto de vista sobre esses projetos.
4. Potencialmente começar a acelerar e fazer algo semelhante ao que RxSwift fez aqui (por exemplo, poderíamos criar vínculos para coisas como Alamofire ). Isso pode ser uma quantidade considerável de trabalho, mas também atrairá novas pessoas para o framework (acho que essa é uma das razões pelas quais o RxSwift está crescendo em popularidade).

Fico feliz em ajudar onde for necessário, pois estou usando Rex e ReactiveCocoa no meu trabalho atual.

@RuiAAPeres fez um tremendo esforço em usar e promover ReactiveCocoa e Rex, acho que ele pode ser um bom colaborador principal. Acho que ainda há muito trabalho a fazer para modernizar as ligações atuais, mas também fornecer novas e ele pode ser um bom trunfo para conseguir isso.

Também estou usando ReactiveCocoa e Rex no meu trabalho atual, então também estou disponível e interessado em ajudar no que puder.

Para sua informação, adicionei a demonstração do Rex no meu playground pessoal https://github.com/inamiy/ReactiveCocoaCatalog/pull/8.
Código muito bom até agora, e acho que apenas migrar para org é suficiente para a primeira etapa :sparkles:

É uma ótima ideia fazer do Rex uma parte oficial da ReactiveCocoa. Como o Swift torna muito fácil dividir o código em vários módulos, mantendo a funcionalidade principal no módulo principal e introduzindo um segundo módulo para as extensões específicas da interface do usuário, definitivamente faz sentido.

Proponho as seguintes alterações:

• Renomear Rex para tornar óbvio que é uma extensão do ReactiveCocoa e é (principalmente) sobre a interface do usuário (conforme declarado por @tonyarnold)
• Alterando o prefixo rex_xxx para rac_xxx para tornar a nomenclatura consistente

@lukaskubanek Concordo com o primeiro ponto, mas tenho opiniões divergentes sobre:

Alterando o prefixo rex_xxx para rac_xxx para tornar a nomenclatura consistente

Embora mantivesse a nomenclatura consistente, tê-lo com nomes diferentes, IMHO, tem várias vantagens:

1. Eu poderia incluir as duas libs no início de um projeto, supondo que precisaria de ambas. Eventualmente, à medida que o projeto evolui, posso parar de usar qualquer um dos operadores do Rex. Uma pesquisa rápida no projeto por rex_ me ajudaria a confirmar isso e removê-lo como uma dependência.
2. Se houver um comportamento estranho em um operador, eu sei imediatamente em qual projeto abrir o problema (sendo uma pergunta ou um bug).
3. Ele ajuda os iniciantes a entender quais são os operadores principais, de onde todos os outros são construídos.

Discutimos mover o código Swift principal, o código Obj-C e a ponte Swift <-> Obj-C em repositórios separados (#2807), deixando esse repositório para as ligações Cocoa… Então, acho que devemos mover o Rex código neste repositório como RAC 5.

@neilpa @NachoSoto O que você acha?

A dependência das ligações Rex e Swift nas APIs ReactiveCocoa ObjC seria removida durante a separação, ou seja, reimplementada no Swift? Caso contrário, a IMO dividida não seria realmente eficaz em outras coisas além da manutenção, já que os usuários do Swift ainda precisam construir toda a biblioteca ObjC para apenas alguns métodos em ponte.

A dependência das ligações Rex e Swift nas APIs ReactiveCocoa ObjC seria removida durante a separação, ou seja, reimplementada no Swift?

Sim! Definitivamente envolveria algum Objective-C, mas não envolveria ReactiveObjC.

Então acho que devemos mover o código Rex para este repositório como RAC 5.

Concordo, mas precisamos ter cuidado com o histórico de recompra. Devemos traçar um plano para gerenciar o movimento/rebase/split que mantenha um histórico de repo sensato.

Há também ramificações para questões em aberto para as quais não temos a opção subtree split potencial.

Suponho que isso seja feito agora, graças ao #3210!