Цитата из лекции по SwiftUI: Imperative View
Если слышите, что идет речь об императивной модели разработки пользовательского интерфейса или об императивной модели кодирования в целом, то думайте о том, что слово “императивный” (imperative) имеет тот же корень, что и слово “имперский” (imperial).
Имперское государство — это государство, в котором правит император и он говорит своим подданным: “Делайте это, стройте это, сажайте эти поля и т.д.” Император говорит, что нужно делать людям, и таким способом “живет” имперское государство.
Следуя этой метафоре в Мире UI, ВЫ говорите, где разместить ту или иную кнопку, как организовать UI элементы на экране и для того, чтобы это сделать, вы все время вызываете функции.
Чем же плоха императивная модель разработки пользовательского интерфейса (UI)?
Главная причина состоит в том, что вам приходится иметь дело со ВРЕМЕНЕМ.
Все эти UI элементы, все эти функции для их создания вызываются в определенное время.
Разместите кнопку в этом месте, а затем позже мы изменим её заголовок, а затем ещё позже мы сделаем её видимой или что-то ещё.
Если вы хотите понять, как работает ваш императивный UI, вам придется иметь дело с ещё одним измерением, а именно со временем, то есть вам нужно знать, КОГДА вызываются те или иные функции и как их вызов зависит от вызовов других аналогичный функций. Если ваш UI сформировался и работает в данный момент, то кто угодно может вызвать любую функцию, меняющую ваш пользовательский интерфейс. Вам все время нужно быть на страже и готовым ко всему. Это просто кошмар управлять таким UI и самое главное, практически невозможно доказать, что ваш UI действительно работает, ведь вы не можете вызывать каждую функцию отдельно во всевозможных обстоятельствах.
Различие между декларативным и императивным стилями
В противоположность этому, при ДЕКЛАРАТИВНОМ способе представления UI вы ВСЕГДА сможете посмотреть на описание UI и четко увидеть, что он показывает. Вы можете сделать это в любое время, потому что описание UI НЕ зависит от ВРЕМЕНИ.
Его можно спросить в любой момент времени, что он делает, что он рисует, и для этого достаточно посмотреть на код, который находится прямо перед вами.
Все, что рисуется на вашем UI находится прямо перед вами.
Тот код, который мы писали на прошлой Лекции, и является тем самым полным кодом, предназначенным для показа наших карт, и больше нигде нет никакого другого кода, который будет вызывать какие-либо функции, связанные с этим кодом, и все портить.
Позже сегодня вы узнаете, что структуры struct, а все наши Views являются структурами structs, по умолчанию являются read-only (только для чтения). Поэтому никому не разрешено вызывать функции, которые их изменяют, это совершенно невозможно.
Таким образом, вы можете быть уверены, что этот View всегда будет выглядеть в точности так, как видите это в коде, который декларирует его и находится перед вами в данный момент.
Это огромное преимущество в понимание того, как этот код работает состоит в том, что вы абсолютно уверены в том, что никакие случайные вещи не произойдут с вашими Views во время работы вашего приложения
Это фантастика.
Огромное улучшение по сравнению с императивными моделями проектирования UI.
