Комментарии 19
Как раз искал красивое решение для этой проблемы, чтобы не создавать тучу флагов состояния внутри $scope.
Все круто, но имеет место реализация тут www.bennadel.com/blog/2441-Nested-Views-Routing-And-Deep-Linking-With-AngularJS.htm с вашим решением, быть схожей? Я не говорю, что это то же самое, просто подход.
Будьте добры опишите, что не устроило в ui-router.
Да, было интересно.
Они перегрузили библиотеку функциональностью. Для моих задач нужно просто дерево вложенных друг в друга view, завязанных на стандартный роутинг, а не сложная концепция отдельно стоящих state. То есть я не хотел забивать микроскопом гвозди. Больше кода — больше багов, тем более что ui-router до сих пор не в релизном состоянии, а мой код отлажен на реальных проектах уже достаточно хорошо.
А также обратите внимание на параметры сегмента
Извечный вопрос универсального vs созданного под свои нуждны. Почти все, что брали у angular-ui, потом каким-то образом дотачивали под свои нужды. Объемы кода все же не те, когда не стоит браться за свою реализацию.
watcher
, untilResolved
, resolveFailed
. Т.е. инструмент заточен не только с точки зрения, что отсутствует все ненужное. Но еще добавлено нужное.Извечный вопрос универсального vs созданного под свои нуждны. Почти все, что брали у angular-ui, потом каким-то образом дотачивали под свои нужды. Объемы кода все же не те, когда не стоит браться за свою реализацию.
Не совсем понял: Иерархия ограничена только 2 уровнями вложенности?
Скажите пожалуйста, поддерживается ли вложенный роутинг в режиме HTML5 ($locationProvider.html5Mode(true), который без '#')?
Вы продолжаете поддерживать библиотеку?
Скажите, а можно ли с помощью Вашей реализации изменить parent state без перегрузки всех его child'ов?
Подскажите, можно ли использовать параметр из dependencies в resolve функции? Если да, то как? В вашем примере вы используете параметр только в контроллере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Nested routing в AngularJS