The Composable Architecture — лучшие практики

Чтобы придерживаться подхода boundaries approach (основанного на границах), лучше всего называть действия view (вью, вьюшка, представление) на основе того, “что произошло” (what happened), а не их ожидаемого эффекта. Например, вы должны использовать .didTapIncrementButton вместо .incrementCount. Этот подход позволяет вам добавить логику к действию, сохраняя при этом правильное название. Кроме того, эта практика поощряет сохранение бизнес-логики в редукторе, а не позволяет ей проскальзывать на уровень view.

Старайтесь избегать выполнения дорогостоящих операций в Reducers. Reducers выполняются в основном потоке, и такие операции могут вызывать задержки или даже зависание UI (пользовательского интерфейса). Вместо этого рассмотрите возможность использования .task/EffectTask и environment clients (клиентов среды), которые позволяют выполнять эти операции вне основного потока. Таким образом, вы можете гарантировать, что ваше приложение останется отзывчивым и производительным.

При обнулении state (состояния) важно отменить регистрацию любых длительных эффектов, чтобы предотвратить утечку памяти и ошибки. Для этого вы можете использовать метод .cancellable для отмены любых текущих эффектов до того, как state будет освобождено. Таким образом, вы можете гарантировать, что ваше приложение будет эффективно использовать память и оставаться стабильным.

При использовании методов concatenate и merge важно учитывать их различия. Метод concatenate будет ждать завершения предыдущих эффектов, прежде чем запускать следующие, в то время как метод merge запускает эффекты параллельно. Однако важно отметить, что использование concatenate может стать проблематичным при использовании других действий, которые могут привести к задержкам в будущем, таких как анимация. Это также может отсрочить любые последующие эффекты. Поэтому часто лучше использовать метод merge, чтобы обеспечить параллельное выполнение эффектов и предотвратить задержки, которые могут повлиять на взаимодействие с пользователем.

· Избегайте высокочастотных действий, таких как Timers (таймеры), нажимающие на редуктор, чтобы что-то проверить. Вместо этого выполняйте работу в задачах или клиентах env и отправляйте действия обратно только тогда, когда необходимо выполнить реальную работу над State. Примером могут быть обработчики перемещения мыши. Когда мы отслеживаем движение мыши, мы часто делаем это, ожидая выполнения некоторого условия. Лучше всего проверить это условие в коде views, а затем передать только edge condition/events (условие/события) в TCA.

Не используйте действия для обмена логикой. Это не методы. 1.Отправка действий не так проста, как вызов метода для типа. 2. Каждое (асинхронное) действие вызывает изменение области видимости и проверку на равенство в нашем приложении. 3. Единственное исключение на данный момент: действия .delegate(). 4. Вместо этого используйте изменяющие методы для объектов State. В настоящее время изучается альтернатива расширения реализации ReducerProtocol с помощью функций, которые принимают inout State variable (входную переменную состояния). Это позволяет получить доступ к зависимостям Reducer, не передавая их во вспомогательные методы.

По возможности лучше использовать в приложении state функции вместо проецируемого состояния (computed properties – вычисляемых свойств). Это может помочь вам избежать ненужных вычислений и повысить производительность вашего приложения. Например, в вашем AppReducer лучше использовать localWindows вместо вычисляемого свойства windows, если оно доступно. Поступая таким образом, вы можете избежать вычисления свойства windows каждый раз при доступе к нему, уменьшая нагрузку на основной поток и повышая общую производительность приложения.

При использовании редукторов onChange важно быть осторожным и помнить о том, где вы добавляете их в композицию редуктора. Это связано с тем, что редукторы onChange работают только на определенном уровне композиции редуктора. Если у вас возникли проблемы с неработающими редукторами onChange, скорее всего, они добавлены на неправильный уровень редуктора. Например, вы можете наблюдать на уровне функций, но изменение происходит на уровне приложений. Чтобы решить эту проблему, убедитесь, что вы добавили редукторы onChange на соответствующем уровне композиции редуктора, чтобы убедиться, что они функционируют должным образом.

При наблюдении за действиями дочерних функций используйте действия делегирования из нашего boundaries convention (соглашения о границах).

Будьте особенно осторожны с кодом внутри scope (области видимости) функций, например, с вычислением дочернего state.

! Эти вызовы происходят для каждого действия, отправляемого в систему, поэтому они должны быть быстрыми.

! Старайтесь избегать вычислений. Даже сложность O(n) вызовет проблемы в hot paths (горячих путях) для больших боковых панелей.

! Либо предварительно вычислите heave data (тяжёлые данные), либо заставьте уровень view вычислить их, если это необходимо.

! Будьте особенно осторожны при использовании вычисляемых свойств, так как они могут быть дорогостоящими из-за тех же проблем, что и обычная область. Помимо того, что они находятся в hot-path, они часто могут воссоздавать объекты каждый раз, когда их вызывают.

Делайте state optional (необязательным), когда это возможно, и используйте ifLet и optional откаты, чтобы избежать выполнения ненужной работы. Например, command bar (панель команд) была not optional, поэтому её побочные эффекты state/reducer и уровня view работали, даже когда она не была видна.

Состояние UI (пользовательского интерфейса) не всегда должно сохраняться. Например, наведение на боковую панель раньше было свойством state, но оно должно жить только на View Layer.

Будьте осторожны при обновлении объектов persisted (постоянного) state. Они могут потребовать миграции. Обязательно добавьте тесты, чтобы избежать потери пользовательских данных.

Additional reading on PointFree Dependencies system