там прям про ui

о!

про дифы итп

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

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

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

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 в каждом элементе как в реакте, потом все это собирается движком и процессится в новый стейт

ну не знаю, так что-то сходу не складывается как apple может не ломая всё вставить фоновый layout и кэширование

Сейчас ты после смены констрейнтов вызываешь апдейт, но легко сделать так, чтобы система сама это делала

Почему нет?

Immutable data structures в констреинтах

и пожалуйста

делай что хочешь в фоне

потом скорми новый набор движку

чтобы посчитать layout нужны не только констренты но и вся иерархия вьюшек в которых выставлены такие вещи как текст, картинки, паддинги итп. чтобы за кэшировать резултаты надо быть увереным что иерархия не изменится при следующем проходе, а она может

Вот есть браузер. На вход подается грубо говоря XML, на выходе - картинка в окне.

Твой xib файл - тот же xml

пожалуйста, меняй иерархию, если у тебя весь стейт представлен в виде данных

потом отдашь движку новую иерархию целиком

он применит

не ну так можно конечно, если полность сделать новый tableview, жесткое api

но с текущим не выйдет

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

по-крайней мер нет гарантий, что следуют

ну смотри - иерархия в виде данных у тебя уже есть

это твои UIView

как пользователь tableview я могу накодить вообще без данных

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

Ну да

Это твой новый стейт

У тебя был старый стейт, стал новый

можно посчитать диф и отрендерить

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

так же как и новые значения для геометрии view

Представь, что ты на каждом фрейме копируешь всю иерархию view

потом меняешь копию в своих контроллерах

потом из старой и новой можно дифы считать, кэшировать итд

что-то уже смешались дифы и кони. диф это набор операций чтобы превратить состояние_1 в состояние_2. дифы нет смысла кэшировать, они не используются дважды. диф это к примеру - 1. удалять row1 2. обновить секцию3 3. установить новый title

Ты можешь закэшировать старое состояние

Дифы это просто чтобы не обновлять всю иерархию

ладно пример. вот инженер apple, а вот есть tableview, как ему в нем закэшировать layout ячеек, чтобы автоматом у всех пользователей заработало в ios11. всё что он может делать это вызывать cellForIndexPath в фоне для невидимых ячеек, а также heightForRow, willDisplay, сделать ячейке layout, и вот он ок, таки получил слепок вьюшек. теперь он может не вызывать cellForIndexPath а использовать из кэша. но это полная жопа, то что этот инженер сделал. во-первых в фоне никто не ожидал что вызовется cellForIndexPath ,. а даже если с божьей помощью приложение не упало и вернуло норм данные, то где гарантии что пока доскролишь до закэшированого данные не поменялись и ячейка должна быть совсем другая. нюансов тысячи, апи tableview абсолютно не готово справиться с такой задачей в одиночку

всё что я хочу сказать, что с текущим апи ничего не сделаешь и надо городить аля asyncdisplaykit если хочешь кэшировать и считать вещи в фоне

может быть apple что-то выкатит

но это будет даже не uikit

погоди погоди

причем тут cellForIndexPath

и что ты хочешь закешировать

layout для несуществующих ячеек?

Это невозможно