И каким боком это относится к Clean Architecture

ну они там далеко не всё додумали

интеракторы к примеру в том виде как на objc вообще хрень

Не, базовая идея понятна - разделите ваш mvc код на более простые модули.

ну так вайпер от мвц никуда и не ушел

короч я тут скидывал гифку

А вот дальше какое-то сочинение на тему "как я провел лето"

С конфы)

йеп

У Вайпера вроде есть плюсы.. но у нас проект сначала был красивый, все аккуратно и правильно) а по итогу оброс говном и костылями к концу

да там вообще минное поле

красота будет при очень четком подходе и анлиме времени

Ну вообщем берем стандартный айфоновский MVC, обмазываем проксями и калбеками и вуаля.

А на предыдущем проекте мне дали баги фиксить.. так там чел впилил mvvm и rac

Причём только на одном экране)

не не должна быть конечная цель

коммунизм

https://habrahabr.ru/company/badoo/blog/281162/

Я вот смотрю на unidirectional dataflow фреймворки

По принципу реакта

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52#.9rzvaai9l

оригинал

Но пока не оч понятно как это ляжет на то, что сейчас есть в проекте

Вот там было весело. Весь проект хер пойми на чем.. и тут mvvm rax))

Rac

да статья популярная

но не глубокая

какой там второй круг

тысячи их

Про глину давайте )

Видимо наболевшие темы :)

unidirectional dataflow кстати норм идея но опять же это детали реализации того же mvc/mvp/mvvm

я бы не сказал

Во всех MVX bidirectional binding

с чего бы это взялось такое правило?

а где unidirectional

всмысле где

Ну в каком из паттернов?

в каком хочешь в таком и сделаешь

Идея у реакта такая, что новый стейт собирается из текущих событий\данных и разом применяется к view

ну так а что мешает так делать даже когда фигачишь всё в одном viewcontroller

Нет структуры, которая описывает стейт

Нельзя взять стейт А и стейт B и посчитать между ними дифы, например

ну так в самом ios ясное дело что нету такого

надо писать самому

Уже есть попытки

да даже apple на wwdc пыталась

про сны там что-то

тоже диф считали итп

например катана https://github.com/BendingSpoons/katana-swift

А можешь ссылку дать на wwdc?

ну вот у меня очень похожу скаладывается на катану

Я помню value programming with swift было, но это немного не про то.

не везде я с ними согласен

https://developer.apple.com/videos/play/wwdc2016/419/

А, не

Точнее это по этой теме, но не про то как это в UI использовать

всмысле

там прям про ui

о!

про дифы итп

да, перепутал с другим, сорри

вопрос только в лейауте

ERROR: S client not available

катана решает кастомным движком

Katana has its own language (inspired by Plastic) to programmatically define fully responsive layouts that will gracefully scale at every aspect ratio or size

ага у меня есть свой

LayoutOps

тоже умеет ноды считать, можно и в бэкграунде

ну autolayout в печку, никогда им не пользовался

но бонус просчитать всё и получить суперплавность решает

Я писал без него одно время.

тем более autolayout имеет далеко не самое приятное api

Пришел к бажному автолейауту, в котором была половина функциональности от нативного минус визуальный редактор

Сейчас пофиксили апи

есть анкоры

есть фреймворки поверх autolayout, в которых можно проще определить

когда у тебя айфон, айпад и две ориентации на каждом - мало приятного вручную считать

ну так вручную никто не считает

https://github.com/psharanda/LayoutOps/blob/master/README/DEMOS.md

autolayout не посчитаешь в background, не закэшируешь результаты

Да, есть такое

Поэтому кастомные движки, да

есть еще asyncdisplaykit, но что-то они перебрали в нем

слишком сложно внутри

В принципе сам autolayout построен на опенсорсной библиотеке для решения уравнений в constraints

AsyncDisplayKit’s layout engine is both one of its most powerful and one of its most unique features. Based on the CSS FlexBox model, it provides a declarative way of specifying a custom node’s size and layout of its subnodes. While all nodes are concurrently rendered by default, asynchronous measurement and layout are performed by providing an ASLayoutSpec for each node.

Неудивительно :)

что внутри сложно

Но я думаю эппл тоже к этому придет

Учитывая что по сути constraints - это и есть стейт

можно добиться всего этого меньшей кровью

и его несложно собрать, сохранить и применить

не переписывая пол uikit

В идеале ты даже не заметишь

Ты делаешь функции для смены constraints в каждом элементе как в реакте, потом все это собирается движком и процессится в новый стейт