Хорошая мысля приходит опосля

Часто бывает так, что написав какой-то код, который успешно где-то работает, начинаешь замечать его несовершенства. Так случилось с алгоритмом слияния макета компонента с объектом с данными для нужд Duit.

Дано: два экзепляра Map, где один из них - это сам макет, а второй - набор данных. Во вложенных структурах внутри Map можно найти объекты вида [{"objectKey": "oKey", "attributeKey": "aKey"}] , которые представляют собой ключи в двух объектах (откуда берем значение и куда его присваиваем).

Предыдущее решение: когда требуется отрисовать компонент, мы рекурсивно обходим всю вложенную структуру, ищем там такие объекты и выполняем над ними необходимые манипуляции.

Вопрос: какого лешего я сразу не заметил, что это не оптимально? Насколько много итераций придется сделать по макету сложного компонента с большой вложенностью? А если мы при этом пытаемся отрисовать их в спике, где необходимо выполнять подобную оперцию быстро?

Новое решение можно посмотреть тут. Кратко о новом алгоритме:

1. При регистрации компонента мы выполняем ту же операцию - рекурсивный обход структуры. 1.1. Когда встречаем внутри ValueReference - создаем для него экземпляр класса-контейнера, который помимо самого ValueReference хранит и ссылку на объект, в котором он был найден, ну и сохраняем этот экземпляр в Set. 2. Когда требуется отрисовать компонент - берем описание макета и итерируемся по сету, откуда получаем ссылку на нужный нам объект, модифицируем его с данными, которые пришли с бэка. 3. Профит, теперь сложность алгоритма слияния О(n), оценивать сложность прежнего алгоритма даже не берусь 😁

Вывод: надо думать башкой, прежде чем код писать 😂