example - Cuándo usar Observable vs EventEmitter vs Dot Rule para la detección de cambios en angular2

observable angular 6 ejemplo

Question

Hay tres métodos que he visto para gestionar la detección de cambios en Angular2.

1. Observables

   @Injectable()
   export class TodosService {
   todos$: Observable<Array<Todo>>;
   private _todosObserver: any;
   private _dataStore: {
   todos: Array<Todo>
   };
   constructor(private _http: Http) {
   // Create Observable Stream to output our data
   this.todos$ = new Observable(observer =>
   this._todosObserver = observer).share();
   this._dataStore = { todos: [] };
   }
   }

2. EventEmitter.

   @Injectable()
   class NameService {
   name: any;
   nameChange: EventEmitter = new EventEmitter();
   constructor() {
   this.name = "Jack";
   }
   change(){
   this.name = "Jane";
   this.nameChange.emit(this.name);
   }
   }

3. Regla de puntos

   export interface Info {
   name:string;
   }
   @Injectable()
   class NameService {
   info: Info = { name : "Jack" };
   change(){
   this.info.name = "Jane";
   }
   }

Mi pregunta es, las tres implementaciones pueden funcionar al suscribirse para ver los cambios en los datos. ¿Cómo decide cuándo usar uno en lugar del otro y cuáles son los inconvenientes de cada uno?

Answer 1

Además de lo anterior, necesitamos usar Event Emitter para el enlace de eventos entre un componente secundario y uno primario. Es mejor que evitemos suscribirnos a él, ya que si en el futuro está en desuso, el código debería cambiarse nuevamente. Por lo tanto, es mejor evitar el uso de emisores de eventos, excepto el enlace de eventos entre un componente secundario y uno primario. En otros escenarios, es mejor usar Observable''s. Consulte este enlace para obtener más información ... https://www.bennadel.com/blog/3038-eventemitter-is-an-rxjs-observable-stream-in-angular-2-beta-6.htm#comments_47949

Answer 2

Intentemos darte algunas pistas ...

El principal problema con el último enfoque es que no funciona con tipos primitivos sino solo con referencias. Entonces no lo recomendaría ...

Creo que EventEmitter / Observable es el enfoque correcto para implementar y manejar eventos personalizados. También está vinculado a los propios componentes ( @Ouput ), el mapeo bidireccional en plantillas (sintaxis [(...)] ) y la tubería async .

A partir de la documentación, EventEmitter usa Observable pero proporciona un adaptador para que funcione como se especifica aquí: https://github.com/jhusain/observable-spec . Después de mirar la clase EventEmitter de Angular2, extiende la clase Subject . Es un poco más que un simple Observable . Consulte este enlace para obtener más detalles: https://github.com/Reactive-Extensions/RxJS/blob/master/doc/gettingstarted/subjects.md

Con respecto a la creación de un observable personalizado, yo diría: cree sus propios observables solo cuando necesite algo específico. De lo contrario, aproveche la clase EventEmitter . Pero hay muchas cosas que puede hacer con la clase EventEmitter y los operadores observables.

Para concluir, en un caso de uso tan "simple", las cosas no son tan obvias, pero en escenarios más complejos, EventEmitter / Observable permite definir una cadena de manejo utilizando operadores. La muestra clásica es actualizar una lista de acuerdo con un valor para una input (aquí this.term definido en el ngModel del campo):

this.term.valueChanges
.debounceTime(400)
.flatMap(term => this.dataService.getItems(term))
.subscribe(items => this.items = items);

Esta gran publicación de blog de Christoph Burgdorf podría darle algunas ideas sobre lo que los observables pueden manejar: http://blog.thoughtram.io/angular/2016/01/06/taking-advantage-of-observables-in-angular2.html .

Espero que te ayude, Thierry