Конструктор класса Aurelia против Активации

Ответ 1

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

Активировать - один из способов жизненного цикла активации экрана, и в идеале он должен использоваться для управления только режимом экрана/представления. Например, метод canDeactivate контролирует, можно ли перемещаться по модели представления модели и т.д. Активировать также крючок, который выполняется непосредственно перед визуальной моделью (но до attached hook). Однако возможно, что метод activate никогда не будет вызван, скажем, маршрут перемещается в конструкторе или canActivate методы отклоняют/возвращают false - в этом случае конструкция все равно будет вызываться, но активировать не будет.

С другой стороны, метод construct вызывается перед любыми другими крючками и методами, поэтому он вызывается перед activate. По этой причине конструкция является основным местом для настройки свойств конфигурации, поскольку она требует инъекций зависимостей. Таким образом, в то время как активация принимает фиксированный набор параметров (params, routeConfig, navigationInstruction), список параметров, переданный методу constructor, зависит от того, какие службы вы вводите в свой класс модели просмотра.

Ответ 2

Одна большая разница, которую я вижу здесь, заключается в том, что метод активации имеет значение Promis как возвращаемое значение, поэтому вы можете запустить здесь асинхронный код. Запуск асинхронного кода в конструкторе - очень плохая идея. Более подробная информация заключается в том, что конструктор не должен генерировать исключение, поэтому здесь вы просто назначаете параметры конструктора для локальных переменных без любой логики. Я бы больше не делал в конструкторе, и фактическая инициализация видоискателя с логикой должна происходить в активировать или приложенный метод.