change - NgrxStore y Angular: utilice la tubería asincrónica de forma masiva o suscríbase una sola vez en el constructor
router events angular 6 (3)
Otra posibilidad es usar una construcción como esta:
<div *ngIf="person$ | async as per">
<div>{{ per.name }}</div>
<div>{{ per.address }}</div>
<div>{{ per.age }}</div>
<div>
Aunque para bits de código reutilizables, es mejor utilizar el método de componente de presentación.
Tenga en cuenta que esto funciona en el ángulo 5, no estoy seguro acerca de otras versiones.
Estoy empezando a mirar ngrx Store y veo la conveniencia de usar la tubería asíncrona angular. Al mismo tiempo, no estoy seguro de si el uso masivo de la tubería asíncrona angular es una buena opción.
Yo hago un simple ejemplo. Supongamos que en la misma plantilla necesito mostrar diferentes atributos de un objeto (por ejemplo, una Persona) que se recupera de la Tienda.
Un pedazo de código de plantilla podría ser
<div>{{(person$ | async).name}}</div>
<div>{{(person$ | async).address}}</div>
<div>{{(person$ | async).age}}</div>
mientras que el constructor de la clase de componente tendría
export class MyComponent {
person$: Observable<Person>;
constructor(
private store: Store<ApplicationState>
) {
this.person$ = this.store.select(stateToCurrentPersonSelector);
}
.....
.....
}
Por lo que yo entiendo, este código implica 3 suscripciones (hechas en la plantilla a través de la tubería asíncrona) para el mismo Observable ( person$ ).
Una alternativa sería definir 1 propiedad ( person ) en MyComponent y tener solo 1 suscripción (en el constructor) que llene la propiedad, como
export class MyComponent {
person: Person;
constructor(
private store: Store<ApplicationState>
) {
this.store.select(stateToCurrentPersonSelector)
.subscribe(person => this.person = person);
}
.....
.....
}
mientras que la plantilla utiliza un enlace de propiedad estándar (es decir, sin la tubería asincrónica), como
<div>{{person.name}}</div>
<div>{{person.address}}</div>
<div>{{person.age}}</div>
AHORA LA PREGUNTA
¿Hay alguna diferencia en términos de rendimiento entre los 2 enfoques? ¿El uso masivo de la tubería asincrónica (es decir, un uso masivo de suscripciones) va a afectar la eficiencia del código?
Gracias es un avance para cualquier orientación
Puede agregar ".share ()" al final de cualquier declaración observable. Todos sus tubos asíncronos en un observable compartirán la misma suscripción:
this.name$ = Observable.create(observer => {
console.log("Subscriber!", observer);
return observer.next("john")
}).delay(2000).share();
this.httpget$ = http.get("https://api.github.com/").share();
Plunkr demostrando: https://embed.plnkr.co/HNuq1jUh3vyfR2IuIe4X/
Tampoco debe componer su aplicación como componentes inteligentes y de presentación.
Ventajas:
- Toda la lógica de negocios en el controlador inteligente.
- Solo uno suscribirse
- Reusabilidad
- El controlador de presentación tiene solo una responsabilidad, solo para presentar datos y no sabe de dónde provienen los datos. (débilmente acoplado)
Respondiendo la última pregunta:
El uso masivo de la tubería asincrónica afectará la eficiencia, ya que se suscribirá a cada tubería asíncrona. Puede observar esto más si está llamando a un servicio http, ya que llamará a la solicitud http para cada canal asíncrono.
Componente inteligente
@Component({
selector: ''app-my'',
template: `
<app-person [person]="person$ | async"></app-person>
`,
styleUrls: [''./my.component.css'']
})
export class MyComponent implements OnInit {
person$: Observable<Person>;
constructor(private store: Store<ApplicationState>) {}
ngOnInit() {
this.person$ = this.store.select(stateToCurrentPersonSelector);
}
}
Componente de presentación
@Component({
selector: ''app-person'',
template: `
<div>{{person.name}}</div>
<div>{{person.address}}</div>
<div>{{person.age}}</div>
`,
styleUrls: [''./my.component.css'']
})
export class PersonComponent implements OnInit {
@Input() person: Person;
constructor() {}
ngOnInit() {
}
}
Para más información, verifique: