AngularJS / UI-Router: как использовать один контроллер с несколькими именованными представлениями?

0

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

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

Это не идеально для моего сценария. Например, ui-router говорит, что я должен это сделать:

.state('root.profile', {
    url: '@:slug',
    views: {
        'header': {
            templateUrl: 'app/profile/profile-header.html',
            controller: 'ProfileHeaderController as profileHeader'
        },
        'content': {
            templateUrl: 'app/profile/profile-body.html',
            controller: 'ProfileBodyController as profileBody'
        }
    }
});

.. и я бы скорее сделал это:

.state('root.profile', {
    url: '@:slug',
    views: {
        'header': {
            templateUrl: 'app/profile/profile-header.html'
        },
        'content': {
            templateUrl: 'app/profile/profile-body.html'
        }
    },
    controller: 'ProfileController as profile'
});

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

Я уже пользуюсь сервисом для одного контроллера. Я бы не хотел создавать другую службу только для хранения одного набора значений для использования в обоих контроллерах, потому что это все еще не очень СУХОЙ.

Есть ли какая-нибудь работа для чего-то подобного?

  • 0
    Это может помочь вам. codepen.io/ahsx/pen/mDcEd
  • 0
    Хм, да, это работает, спасибо, но я не могу использовать это, потому что это не совсем соответствует моей модульной структуре. Я должен был бы добавить контроллер в файл модуля, который не является bueno: D
Показать ещё 1 комментарий
Теги:
angular-ui-router
angular-routing

1 ответ

1
Лучший ответ

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

1) они имеют одни и те же данные: поскольку у вас есть служба, я полагаю, что служба сохраняет текущее состояние данных, а это означает, что контроллеры используют одни и те же данные.

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

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

Тем не менее, я вижу одно возможное решение, которое вы могли бы решить для разрешения данных и определения контроллера в качестве родителя для состояния профиля. Это root.profile с другим состоянием между root.profile root и root.profile. В приведенном ниже примере два представления (profile-body.html и profile-header.html) теперь могут использовать один и тот же экземпляр ProfileController.

.state('root', { .. })
.state('root.profile', {
    abstract:true,
    controller:'ProfileController as profile',
    resolve: {
       profile:function(yourProfileDataService) {
           //Resolve profile data
       }
    }
})
.state('root.profile.view', {
    url: '@:slug',
    views: {
        'header': {
            templateUrl: 'app/profile/profile-header.html'
        },
        'content': {
            templateUrl: 'app/profile/profile-body.html'
        }
    }
});

Как видно из примера, я также предлагаю использовать свойство разрешения, которое разрешает данные до создания экземпляра контроллера, а затем вводит его в контроллер. Разрешить документы.

  • 1
    Спасибо за предложение @cbass. Я не могу использовать этот метод, потому что я не хочу разрешать данные в контроллер из-за задержки. В настоящее время не работает с моей настройкой с точки зрения UI / UX. Однако размещение абстрактного родительского состояния для контроллера (за исключением разрешения) является хорошим решением.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню