Как стать автором
Обновить

Комментарии 21

Это стёртый комментарий, или что то не так в статье?
Все, увидел в почте. Спасибо за RxMarbles на iOS, по первости очень помогало )
Спасибо за труд. Что касается PDF-ки, то Adobe Acrobat Reader утверждает что она испорченная.
Странно. Вы скачиваете с гитхаба и смотрите на PC, Маке или iPad? PDF я ровнял в деме Acrobat DC под маком. Открывается встроенным просмотрщиком.
На PC у меня стоит PDF-XChange View, показывает прекрасно даже при заходе через браузер в предпросмотре. Поставил читалку от Adobe — тоже все читает.
Попробуйте обновить Acrobat или сменить PDF читалку и отпишитесь о результате, если не сложно. А может PDF скачался ошибками?
Рад, что пригодилось )
Спасибо за статью.
Скажите, в чем создавали графики?
Рад, что не зря заморочился )
Sketch на маке, рекомендую. Хоть это и полноценный графический редактор, а не построитель диаграмм, но благодаря его простоте, после пары минут тюнинга — это стало не важно.
Всегда пожалуйста.
Автор, ты большой молодец! Это действительно большой труд и лично от себя говорю огромное спасибо! Я сам писал статью про RxSwift и рад, что в русскоязычном сообществе наконец-то подхватили эту тему :-)
Спасибо на добром слове. Тема действительно очень интересная, но при этом относиться к ней нужно с осторожностью. Мало того что нужно переформатировать в голове подход к написанию кода, есть очень много нюансов: потоки, использование последних значений, горячая/холодная подписка и т.д. Чтобы написать качественный материал, нужно самому хорошо во всем разобраться. Сейчас отвлекся на другие проекты, но надеюсь попозже осветить RxSwift и со стороны GUI.
хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка

Сильное заявление, конечно, особенно учитывая тот факт, что RAC 4 использует куда больше плюшек языка, несмотря на то что «вырос с Objective-C».
Мог быть не прав, судил по тем обзорам, что были на момент выбора.
Если у вас есть опыт, — может поделитесь чем RAC лучше RxSwift? Я думаю всем будет интересно, мне в первую очередь.
  • RAC рзаличает холодные и горячие observables на уровне типов, их нельзя просто так скомпоновать, что увеличивает количество ошибок, обнаруживаемых компилятором. Однако RxSwift считает это недостатком, и это можно понять, так как это увеличивает порог входа для новых разработчиков.
  • RAC позволяет задать тип ошибки сигнала. Если использовать тип NoError (специальный тип, фактически enum без единого кейза) в качестве типа ошибки, получим compile-time гарантию того, что этот сигнал действительно никогда не завершится ошибкой. Это очень важно, например, для UI-биндингов.

В целом сложно однозначно сказать, что хуже, а что лучше. RxSwift — почти идетничный порт Rx.NET, что дает пользователям RxSwift возможность легко переносить опыт с других платформ, на которых есть Rx, это однозначно плюс.


RAC же, в свою очередь, пытается решить проблемы оригинального Rx, предоставить больше compile-time гарантий ценой ухода от оригинального Rx API.

Да, про эти два различия я уже встречал. И пожалуй по обоим пунктах мне более импонирует подход RAC.
Т.к. все что отслеживается на уровне компиляции — благо.
В RxSwift нужно при работе с GUI постоянно перехватывать ошибки и наворачивать защиту вида catchError и возвращать другой Observable, или полноценно работать с retry/retryWhen.

С другой стороны — переносимость Rx меня и подкупила.
Но вы упомянули про большее количество Swift плюшек у RAC 4, не моли бы вы привести примеры, если не сложно.

Ну, по мне эти фичи как раз показывают разумное использование системы типов (а это вполне себе Swift-плюшка) во благо.


Ну и конечно protocol extension, кастомные операторы для биндинга, etc. Но это и в RxSwift есть.

Ясно, спасибо за то, что поделились опытом. При наличии свободно времени — посмотрю в сторону RAC. В любом случае выбор между RxSwift и RAC изначально был сделан не по религиозным причинам, так что препятствий для изучения обоих фрейморков нет.
Отлично, большое спасибо )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации