Estados nesteds o vistas para el diseño con la barra izquierda en el ui-router

Tengo el siguiente diseño:

enter image description here

La barra lateral y la barra de encabezado siempre estarán presentes, aunque su contenido es específico del contexto.

Creo que hay dos opciones aquí: estados nesteds (sidenav> Headerbar> Content) o con vistas (si lo entiendo correctamente). Todavía estoy luchando para que mi cabeza se adapte al enrutador ui independientemente de la cantidad de videos y artículos que he leído.

Al hacer clic en Sidenav se cargaría un estado (o vista) en el Contenido y la barra de encabezado ajustaría su contenido en función de lo que se cargue en el Contenido.

Mi sensación es que los estados nesteds parecen ser el enfoque directo más simple, particularmente cuando se piensa en la herencia.

Mirándolo desde otro punto de vista, parece que podrían ser hermanos (aunque los problemas de herencia probablemente me hagan equivocar). Mi idea es que las vistas me permitirían una mayor flexibilidad en el futuro con subtemas y demás.

Y, por supuesto, ng-include y directivas podrían jugar en esto.

Ser nuevo en ui-enrutador podría alguien darme una bofetada en la dirección correcta? Donde estoy atascado está cargando la vista de inicio. Quiero que mis usuarios vean su panel en la sección Contenido una vez que inician sesión. Y luego, ¿cómo cargo elementos nuevos en el Contenido mientras el usuario navega desde la barra lateral?

Una forma de cómo diseñar el escenario con 1) barra lateral, 2) sección de acción y 3) área principal podría ser como en este ejemplo de trabajo

En primer lugar, el estado raíz . Aquí está el estado raíz llamado ‘índice’. Es abstracto y podría resolve un poco. No afecta el nombre del estado del niño y no extiende la url (porque no está definido)

 $stateProvider .state('index', { abstract: true, //url: '/', views: { '@' : { templateUrl: 'layout.html', controller: 'IndexCtrl' }, 'top@index' : { templateUrl: 'tpl.top.html',}, 'left@index' : { templateUrl: 'tpl.left.html',}, 'main@index' : { templateUrl: 'tpl.main.html',}, }, }) 

El primer estado real es list, y hereda de parent pero con un atributo parent: 'index' , por lo que el nombre padre no está afectando el nombre del estado.

La ventaja es que podría heredar muchas cosas resueltas. Además, el estado raíz podría cargarse una vez, para todos los demás estados principales

  .state('list', { parent: 'index', url: '/list', templateUrl: 'list.html', controller: 'ListCtrl' }) 

Este es el verdadero poder de UI-Router, porque ahora podemos ver que el niño está inyectando cosas en dos lugares: 1) sección de acción y 2) área principal

  .state('list.detail', { url: '/:id', views: { 'detail@index' : { templateUrl: 'detail.html', controller: 'DetailCtrl' }, 'actions@index' : { templateUrl: 'actions.html', controller: 'ActionCtrl' }, }, }) 

De esta manera, podemos usar vistas con nombre y vistas múltiples en el escenario del mundo real. Por favor, nunca olvides cómo va la definición del scope:

Herencia de scope solo por jerarquía de vistas

Tenga en cuenta que las propiedades del scope solo heredan en la cadena de estado si las vistas de sus estados están anidadas. La herencia de las propiedades del scope no tiene nada que ver con la anidación de sus estados y todo lo relacionado con la anidación de sus vistas (plantillas).

Es muy posible que haya nested estados cuyas plantillas llenan vistas de ui en varias ubicaciones no anidadas dentro de su sitio. En este escenario, no puede esperar acceder a las variables de ámbito de las vistas de estado primario dentro de las vistas de los estados secundarios.

Comprueba que todo en acción aquí

Solo me gustaría compartir mi experiencia. Ahi esta

  • Preguntas y Respuestas similares: Enrutador UI Angular – Estados Anidados con múltiples diseños
  • y un enlace al plunker de trabajo

El fragmento de la def del estado:

 $stateProvider .state('index', { url: '/', views: { '@' : { templateUrl: 'layout.html', controller: 'IndexCtrl' }, 'top@index' : { templateUrl: 'tpl.top.html',}, 'left@index' : { templateUrl: 'tpl.left.html',}, 'main@index' : { templateUrl: 'tpl.main.html',}, }, }) .state('index.list', { url: '/list', templateUrl: 'list.html', controller: 'ListCtrl' }) .state('index.list.detail', { url: '/:id', views: { 'detail@index' : { templateUrl: 'detail.html', controller: 'DetailCtrl' }, } 

En pocas palabras, sí uso el enfoque de anidación .

Es similar al “ejemplo central” disponible aquí http://angular-ui.github.io/ui-router/sample/#/ . Es jerárquico (lista de entidades / detalles)

Y además, utilizo el estado de la raíz oculta de la cena:

  • revise los detalles aquí Actualizando objetos resueltos en ui.router estados padres
  • el enlace de examinar

que maneja cosas relacionadas con la seguridad, una vez, y se comparte entre todos los estados secundarios:

 $stateProvider .state('root', { abstract: true, template: '
', resolve: {objectX : function() { return {x : 'x', y : 'y'};}}, controller: 'rootController', }) .state('home', { parent: "root", url: '/home', templateUrl: 'tpl.example.html', }) .state('search', { parent: "root", url: '/search', templateUrl: 'tpl.example.html', })

Espero que aclare esto un poco, porque la potencia del UI-Router que veo en las vistas múltiples, ver el anidamiento, la herencia de scope y la máquina lógica de estado detrás