2016-06-25 15 views
8

Ho appena iniziato a scavare in Angular 2 nell'ultima settimana e (come molti altri a quanto pare) hanno avuto alcuni grattacapi sul percorso. Ho iniziato a lavorare con il router 3.0.0-alpha.7. Quello che voglio veramente fare è condividere alcuni dati recuperati nel mio componente base con questi componenti figlio. Ecco il mio percorso di configurazione.Modo corretto di condividere i dati con percorsi secondari tramite router-outlet? router 3.0.0-alpha.7

[{ 
    path: 'base/:id', 
    component: BaseComp, 
    children: [{ 
     path: '', 
     component: OverviewComp 
    }, { 
     path: 'docs', 
     component: DocsComp 
    }] 
}] 

Quando viene colpito il percorso di base, sto recuperando alcuni dati tramite un servizio basato sul parametro: id. Una volta che i dati sono stati ricevuti, mi piacerebbe che si trasformasse in cascata per i bambini. Speravo che sarebbe stato semplice come mettere @Inputs su OverviewComp e DocsComp, ma ho subito capito che non sembra esserci alcun modo di farlo nel modello considerando che il <router-outlet> è il componente del modello reale. derp.

Qualcuno ha qualche idea su quale sia il modo migliore per fare questo genere di cose?

  • Devo lavorare con una versione precedente del router (deprecata dal router)?

  • Il parametro id deve essere spostato sui componenti figlio?

  • I componenti figlio devono semplicemente accedere al servizio per ottenere gli stessi dati (memorizzati nella cache)?

+0

Vorrei che i bambini raggiungessero il servizio e trasmettessero l'id ai bambini utilizzando un [route param] (https://angular.io/docs/ts/latest/guide/router.html#!#route -parametri) o [stringa di query/param] (https://angular.io/docs/ts/latest/guide/router.html#!#query-parameters). Se i dati sono piccoli, puoi semplicemente inserirli nella stringa di query. –

risposta

3

Devo lavorare con una versione precedente router (router-deprecato)?

È una sfida svilupparsi velocemente quanto Angular2 rovescia il loro concetto di routing :). Però, assicurati di non andare per quello deprecato. Era ancora in versione beta quando hanno scelto di contrassegnarlo come "deprecato", quindi probabilmente non si desidera utilizzare un routing deprecato non stabile.

Il parametro ID deve essere spostato sui componenti figlio?

Direi che dipende dalla struttura. Supponiamo di avere molti percorsi come questo

/user/:id/.... 

Non ha assolutamente senso per risolvere l'utente in un componente che ascolta/user /: id, e farlo volta e non in ciascuna delle componenti figlio. C'è un inconveniente, però, se si desidera rendere l'utente disponibile nelle rotte figlio. L'utilizzo di un servizio va bene per questo scopo, ma è necessario far fronte alla natura asincrona delle richieste HTTP di back-end. Quando viene attivata la route figlio e i relativi componenti vengono visualizzati, la chiamata di back-end potrebbe non essere ancora terminata. Quindi non puoi accedere al tuo servizio direttamente dal tuo componente figlio, devi ottenere anche un osservabile. Ciò aggiunge un po 'di complessità al tuo servizio.

L'altro modo è preferire il sovraccarico sulla complessità e risolvere tutti i dati richiesti nel componente figlio. Ciò significa che, per un percorso come questo

/user/:id/process/:id/edit 

è necessario risolvere sia l'utente e di processo, e, probabilmente, la seconda chiamata per il 'processo' dipende dalla 'user' che deve essere risolto in anticipo. Se hai molte rotte per bambini con molti ID per risolvere il problema, potresti essere un po 'noioso, comunque.

Tenere presente che se si indirizza il segmentoa un componente che deve visualizzare alcuni dati sull'utente e sono necessari anche i dati dell'utente nei componenti figlio, è necessario selezionare la prima opzione. Non ha senso effettuare più chiamate agli stessi dati.

I componenti figlio devono solo ricevere il servizio per ottenere gli stessi dati (memorizzati nella cache)?

Sì, per lo stesso percorso, assolutamente. Ciò consente di risparmiare larghezza di banda e risorse del server. Inoltre, potrebbe essere pericoloso poiché il server potrebbe inviare dati diversi in ogni richiesta successiva (almeno, se non si specifica una versione del documento richiesto). Ovviamente, ogni volta che l'utente attiva un nuovo percorso, scegli autonomamente se presenti dati memorizzati nella cache o chiedi al server un aggiornamento.

+1

Grazie a entrambi per aver risposto al problema principale e aver risposto alle poche domande più piccole che ho posto. Solo per la cronaca ho trovato un modo veramente solido per gestire questo genere di cose è adottare il ngrx/store. rimuovendo la gestione del modello dai componenti rimossi tutte le preoccupazioni che avevo dal momento che potevo fare in modo che i componenti principali richiedessero i dati e avessero le azioni di archiviazione delle chiamate di servizio. In questo modo genitori e figli possono semplicemente iscriversi al negozio e sono tutti aggiornati allo stesso tempo. Immensley modello utile. –

+0

Esattamente! Utilizzo questo pattern da alcune settimane con percorsi figlio e componenti figlio per schemi URL che richiedono il caricamento di un massimo di 4 documenti dal back-end, ognuno a seconda del documento precedente. Non ho ancora incontrato difficoltà. – Matt

+0

Forse sono solo lento ma non riesco a capire quale sia la vera soluzione. –

2

Penso di avere avuto un dilemma simile, ed ecco come mi sto occupando di questo tipo di situazioni. Parametri

1. Obiettivo & ingresso

Quando voglio fare la scissione in una componente bambino dal componente principale cercherò di vedere se questo è un diverso tipo di oggetto di sistema oppure no (in pratica se io bisogno di un percorso completo per esso o posso risolvere il mio collegamento dati utilizzando solo una proprietà come bersaglio/ingresso) non dimenticare:

angolare insiste sul fatto che si dichiara una proprietà target per essere un proprietà di input. In caso contrario, Angular rifiuta l'associazione e genera un errore .

recensione part3 da NG2 tutorial: https://angular.io/docs/ts/latest/tutorial/toh-pt3.html

1. Routing

Per i componenti che si possono definire un nuovo percorso e quindi ottenere i dati in che utilizzando due metodi:

1.1. Dai parametri route e un servizio (è necessario utilizzare un metodo di servizio per il caricamento dei dati, in questo modo è possibile refactoring l'accesso ai dati e mantenere il componente snello e focalizzato sul supporto della vista). Dovrebbe utilizzare i parametri del percorso solo per i filtri o le attività di piccoli lavori e non per i trasferimenti di dati. Ecco una possibile componente:

Object1Routes

import { RouterConfig }   from '@angular/router'; 
import { Object1Dashboard } from './object1.dashboard'; 
import { Object1Edit } from './object1.edit'; 

export const Object1Routes: RouterConfig = [ 
    { 
     path: 'object1', 
     component: Object1Dashboard, 
     'children': [ 
      <...> 
      ,{ path: 'edit/:id', component: Object1Edit } 
     ] 
    } 
]; 

Object1Edit

import { Component, OnInit, OnDestroy } from '@angular/core'; 
import { Router, ActivatedRoute } from '@angular/router'; 
import { Object1Service } from './services/object1/object1.service'; 
import { Object1Model } from './models/object1/object1.model'; 

@Component({ 
    selector: 'object1-edit', 
    templateUrl: './object1/object1.edit.html', 
    directives: [] 
}) 

export class Object1Edit implements OnInit, OnDestroy { 

    model = new Object1Model; 

    sub:any; 
    editId:number; 

    constructor(
     private route: ActivatedRoute, 
     private router: Router, 
     private serviceData: Object1Service 
    ) { } 

    onSubmit(d:Object1Model) { 
     this.model = d; 
     this.router.navigate(['/object1']); 
    } 

    ngOnInit() { 
     this.sub = this.route.params.subscribe(params => { 
      this.editId = +params['id']; // (+) converts string 'id' to a number 
      this.serviceData.getObject1ById(this.editId).then(data => { 
       this.model = data; 
       }); 
      }); 
     }); 
    } 

    ngOnDestroy() { 
     this.sub.unsubscribe(); 
    } 
} 

1,2. Proprio da un servizio

Object1Routes

import { RouterConfig }   from '@angular/router'; 
import { Object1Dashboard } from './object1.dashboard'; 
import { Object1List } from './object1.list'; 

export const Object1Routes: RouterConfig = [ 
    { 
     path: 'object1', 
     component: Object1Dashboard, 
     'children': [ 
      { path: '', component: Object1List } 
      <...> 
     ] 
    } 
]; 

Object1List

import { Component, OnInit, OnDestroy } from '@angular/core'; 
import { Router, ActivatedRoute } from '@angular/router'; 

import { Object1Service } from './services/object1/object1.service'; 
import { Object1Model } from './models/object1/object1.model'; 

@Component({ 
    selector: 'object1-list', 
    templateUrl: './object1/object1.list.html' 
}) 

export class Object1List implements OnInit, OnDestroy { 

    constructor(
     private route: ActivatedRoute, 
     private router: Router, 
     private serviceData:Object1Service 
    ) { } 

    modelArray:Object1Model[]; 
    selectedId:number; 
    private sub: any; 

    onSelect(model:Object1Model) { 
     console.log('Select ' + model.code); 
     let link = ['/object1/edit', model.id]; 
     this.router.navigate(link); 
    } 

    onDelete(model:Object1Model) { 
     console.log('Delete : ' + model.code); 
     this.serviceData.delObject1ById(model.id); 
    } 

    ngOnInit() { 
     this.sub = this.route .params.subscribe(params => { 
      this.selectedId = +params['id']; 
      this.serviceData.getAllObject1().then(data => this.modelArray = data); 
     }); 
    } 

    ngOnDestroy() { 
     if (this.sub) { 
      this.sub.unsubscribe(); 
     } 
    } 
} 

Spero che questo vi aiuterà. Fammi sapere i tuoi pensieri, se hai un'opinione diversa o se ho perso qualcosa.

Il codice fornito è basato su Angular 2.0.0-rc.2 e @ angular/router 3.0.0-alpha.7.

controllare anche questo articolo sul Responsabilità unico principio: https://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

+0

Ecco un esempio completo che è possibile utilizzare: http://plnkr.co/edit/Zd0qmavTzedtimImAgfQ?p=preview – Gabi

Problemi correlati