Reactivecocoa: Перемещение Rex в организацию ReactiveCocoa

Я за перевод Рекса в организацию ReactiveCocoa. Это началось как личная игровая площадка, но превратилось во что-то более полезное. Я также больше не использую RAC в своей повседневной работе, поэтому имеет смысл передать ответственность сообществу.

Прежде чем нажать на курок, я хотел бы знать, что думают по этому поводу @NachoSoto и @mdiep .

Я был бы полностью согласен. Я бы предложил сделать проход / быструю проверку кода (я рад это сделать), чтобы убедиться, что операторы / реализации соответствуют стандарту (я не сомневаюсь в этом для хотя бы на одну секунду, зная @neilpa :)), но просто чтобы убедиться, что мы:

• знают, какие операторы нам нужно поддерживать (возможно, удаляя некоторые? idk).
• убедитесь, что мы определили области улучшения и открытые проблемы.

Если целью является сделать библиотеку более доступной, я бы предложил более формальное имя, которое могло бы помочь в этом. «Рекс» не напоминает ReactiveCocoa, когда я его вижу. Не уверен, какое имя правильное, но что-то с «ReactiveCocoa» или даже просто «Reactive» в названии было бы лучше, IMO.

Я действительно не смотрел на Rex, но мне нравится идея библиотеки, ориентированной на пользовательский интерфейс, в рамках организации ReactiveCocoa. Рекс кажется хорошим началом. 👍 Я думаю, что @NachoSoto сначала посмотрит на это, это тоже отличная идея.

Я действительно думаю, что нам нужно найти еще несколько основных участников RAC в целом. Кажется, что все были довольно тонкими.

@tonyarnold это может помочь. ✨

@mdiep Я согласен. Тем не менее, Rex нуждается в некоторой доработке в плане документации (README). Может быть, создать каталог, чтобы люди знали, какой пользовательский интерфейс он предоставляет, вместо того, чтобы проверять исходный код. Конечно, есть и другие операторы, которые также должны быть задокументированы.

Я действительно думаю, что нам нужно найти еще несколько основных участников RAC в целом. Кажется, что все были довольно тонкими.

Я тоже согласен с этим, здесь есть изрядная работа:

1. Пересмотрите открытые вопросы .
2. Может быть, добавить дополнительные примеры использования , как это было сделано здесь , и иметь для этого документ. Я пытался сделать это с помощью RACNest , но вместо фрагментов кода — с интерактивным проектом.
3. Закройте или обновите некоторые заброшенные проекты (например, этот , этот и этот ). Возможно , @jspahrsummers мог бы поделиться с нами своим взглядом на эти проекты.
4. Потенциально начните набирать скорость и сделайте что-то похожее на то, что сделал здесь RxSwift (например, мы могли бы создать привязки для таких вещей, как Alamofire ). Это может потребовать значительного объема работы, но это также привлечет к фреймворку новых людей (я думаю, это одна из причин роста популярности RxSwift).

Я рад помочь там, где это необходимо, так как я использую Rex и ReactiveCocoa на своей текущей работе.

@RuiAAPeres приложил огромные усилия для использования и продвижения ReactiveCocoa и Rex, я думаю, что он может быть хорошим основным участником. Я думаю, что предстоит еще много работы по модернизации существующих креплений, а также по созданию новых, и он может быть хорошим подспорьем для достижения этой цели.

Я также использую ReactiveCocoa и Rex на своей текущей работе, поэтому я также доступен и заинтересован в помощи во всем, что могу.

К вашему сведению, я добавил демоверсию Rex на свою личную игровую площадку https://github.com/inamiy/ReactiveCocoaCatalog/pull/8.
На данный момент действительно хороший код, и я думаю, что для первого шага достаточно просто перейти на org :sparkles:

Это отличная идея сделать Rex официальной частью ReactiveCocoa. Поскольку Swift позволяет очень легко разделить код на несколько модулей, сохраняя основные функции в основном модуле и добавляя второй модуль для расширений, специфичных для пользовательского интерфейса, определенно имеет смысл.

Я бы предложил следующие изменения:

• Переименование Rex, чтобы было очевидно, что это расширение для ReactiveCocoa и оно (в основном) связано с пользовательским интерфейсом (как заявил @tonyarnold)
• Изменение префикса rex_xxx на rac_xxx для согласования именования

@lukaskubanek Я согласен с первым пунктом, но у меня смешанные мнения по поводу:

Изменение префикса rex_xxx на rac_xxx для согласования имен.

Несмотря на то, что имена будут согласованными, ИМХО, наличие разных имен имеет несколько преимуществ:

1. Я мог бы включить обе библиотеки в начале проекта, предполагая, что мне понадобятся они обе. В конце концов, по мере развития проекта, я, возможно, перестану использовать каких-либо операторов Рекса. Быстрый поиск в проекте rex_ помог бы мне подтвердить это и удалить его как зависимость.
2. Если у одного оператора есть странное поведение, я сразу знаю, в каком проекте открыть проблему (будь то вопрос или ошибка).
3. Это помогает новичкам понять, какие из них являются основными операторами, откуда строятся все остальные.

Мы обсудили перенос основного кода Swift, кода Obj-C и моста Swift <-> Obj-C в отдельные репозитории (#2807), оставив этот репозиторий для привязок Cocoa… Поэтому я думаю, что мы должны переместить Rex код в этот репозиторий как RAC 5.

@neilpa @NachoSoto Что ты думаешь?

Будет ли зависимость привязок Rex и Swift от API-интерфейсов ReactiveCocoa ObjC быть удалена во время разделения, т.е. повторно реализована в Swift? В противном случае разделенная IMO не была бы действительно эффективной в других вещах, кроме обслуживания, поскольку пользователям Swift все еще нужно собрать всю библиотеку ObjC всего для нескольких методов моста.

Будет ли зависимость привязок Rex и Swift от API-интерфейсов ReactiveCocoa ObjC быть удалена во время разделения, т.е. повторно реализована в Swift?

Да! Это определенно будет включать в себя некоторый Objective-C, но не будет включать ReactiveObjC.

Поэтому я думаю, что мы должны переместить код Rex в этот репозиторий как RAC 5.

Согласен, но нам нужно быть осторожными с историей репо. Мы должны разработать план управления перемещением/перебазированием/разделением, который поддерживает разумную историю репо.

Есть также разветвления для открытых проблем, у которых у нас нет потенциального варианта subtree split .

Я полагаю, что это сделано сейчас, благодаря #3210!