Когда я наконец-то углубился в оптимизацию производительности и начал изучать, как настоящие опытные инженеры проектируют свои сетевые уровни, это стало для меня настоящим откровением. Я понял, что
.onAppear — это не сетевой инструмент, а событие жизненного цикла пользовательского интерфейса. Использование его для получения данных приводило к гонкам, утечкам памяти и невозможным состояниям интерфейса.Это осознание изменило для меня всё. Оно высветило ту самую грань, которая отделяет хорошего разработчика от отличного:
Начинающий разработчик пишет работающий код. Опытный разработчик пишет код, который безопасно масштабируется и уважает системные ресурсы.
Если вы всё ещё помещаете вызовы API внутрь
.onAppear, пора обновить архитектуру. Вот предельно честная правда о том, почему это ломает ваше приложение изнутри, и как это исправить с помощью .task и машины состояний.Статья: https://apptractor.ru/info/articles/prekraschaem-ispolzovat-onappear-dlya-api-vyzovov-osvaivaem-task-i-konechnyy-avtomat.html
Платформа: iOS
👨🦯➡️ AppFiles: код, инструменты, практики, производительность