Угловой UI-маршрутизатор приостанавливается до выполнения контроллера состояния пользователя

Question

Я знаю, что дочернее состояние/контроллер может ждать необходимых результатов асинхронизации, добавив объект обещания к объекту разрешения в свой объект описания состояния. Но использование этого означает, что решение о том, что требуется для состояния, выполняется до запуска контроллера. где в моем случае мне нужно применить логику, чтобы решить, нужны ли мне какие-либо асинхронные данные вообще или нет и какими должны быть эти данные. Я также понимаю, что я могу поместить эту логику в службу, но это будет означать перенос всей логики с контроллера на соответствующую службу [которая является опцией, но чувствует себя «неправильно»].

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

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

Я также знаю, что я мог бы, вероятно, поймать следующее событие StateChangeStarted, установить event.preventDefault=true, а затем использовать $urlRouter.sync() это решение обещания в родительском состоянии. но для него это довольно неудобно.

Я хотел был бы иметь возможность сделать что-то вроде $urlRouter.pause() [нет такого API в момент написания Q], чтобы предотвратить продолжение маршрутизатора, а затем можно позвонить $urlRouter.sync().

Каким будет метод «Угловой способ» для условного приостановки выполнения контроллеров дочерних состояний до тех пор, пока некоторые результаты асинхронизации не будут разрешены родительским состоянием?

Answer 1

С тех пор как я написал этот вопрос Q, я принял точку зрения, что было бы неплохо, если родительское состояние блокирует выполнение дочернего состояния.

Причина в том, что даже когда кажется, что родительское состояние знает, что дочернее состояние ДОЛЖНО иметь некоторые данные, подготовленные для него, чтобы он мог делать свои вещи, по крайней мере возможно, что есть другие вещи, которые могут иметь дочернее состояние до тех пор, пока не появятся необходимые данные.

Мой лучший пример - это родительское состояние, которое готовит данные для отображения на карте - хотя понятно, что дочерний элемент не может выполнить рендеринг, пока он не получит данные от родителя - он может, безусловно, начать рендеринг пустую карту и только добавлять данные на карту, когда она доступна.

С этой точки зрения не разрешается и не блокируется выполнение дочернего состояния - это хорошая идея.

То, что я до сих пор делал, заключается в предоставлении обещаний, которые обещают данные, созданные родителем, в область $ scope и используя $q.all($promisService.get(),...).then или только $promisService.get().then, как подходит для каждого конкретного случая.

Это говорит о том, что я пытаюсь приложить обещания к состоянию данных $ data, чтобы они автоматически очищались. Это просто, что я не могу найти достаточно информации о том, как.атрибут данных ведет себя или должен использоваться в динамическом контексте

Answer 2

Если вам нужно использовать данные в дочернем состоянии, которые поступают из родительского состояния, я предлагаю вам установить данные на уровне $rootScope в родительском государственном контроллере и в дочернем состоянии вы можете посмотреть $rootScope и заполнить свою локальную область данными в $rootScope.

Например, в родительском контроллере:

$rootScope.user = User.get();

В контроллере ребенка:

$scope.userData = {..}; 

$rootScope.$watch('user', function(){ 
    //if somehow you need a local userData variable augmented with other types of data 
    $scope.userData.email = $rootScope.user.email; 
});