Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Angular EventEmitter vs. Communication via Service

Tags:

angular

Lets assume we got a deep nested architecture with one main component and 3 layers of subcomponents. For example:

todo->todo list->todo list action bar->todo list button

There will be other components as well.

When we use EventEmitter we would have to go theough all the layers up to todo component. The alternative would be to have a communication service with an observable to communicate from the button component with the todo component.

What are the ups and downs to use the one way or the other? What way should I go for?

like image 933
Max Avatar asked Aug 10 '17 05:08

Max


People also ask

Can we use EventEmitter in a service?

Event-emitter is imported from “@anguar/core” package. It is used in directives and components to emit custom events synchronously or asynchronously and register handlers for those events by subscribing to an instance. Event emitter is a generic type, it can take any additional information.

Should I use EventEmitter or subject?

Conclusion. Use Eventemitter when transferring data from child component to parent component. Use Subject to transfer data from one component to another component.

Why do we use EventEmitter in angular?

What Is EventEmitter in Angular. EventEmitter is a module that helps share data between components using emit() and subscribe() methods. EventEmitter is in the Observables layer, which observes changes and values and emits the data to the components subscribed to that EventEmitter instance.

What is EventEmitter can we use it in service if yes then how do you tell the use case?

EventEmitter is a public, documented type in the final Angular Core API. Whether or not it is based on Observable is irrelevant; if its documented emit and subscribe methods suit what you need, then go ahead and use it. Once a reference implementation of the spec is available, switch to it.


1 Answers

This is a design perspective .

Generally what i have figured out is if the application size is medium to huge then go for Shared services using either Behaviour Subject or Replay Subject to transmit message to other components .

And even better design is to go for ngrxi:e using redux in Angular. the only downside to this is the extra code you need to write for your actions and reducers but the plus is all the logic is separated from the components which in redux world are know as dumb components. Once done it will be a life saver using ngrx dev tools to track state at any moment in time, and it will be easy for you to track which event or action is fired when and how to debug and make additions to code .

Only if your app size is small i will suggest you to go with Event emitters as with multiple nested components you are engulfed in a spaghetti code . You cannot keep track of all the firing events and then you end up re writting your code .

More on using Event Emitters vs Shared Services LINK.There is a particular question just for that.

More on ngrx LINK. This link uses ngrx v2.

I have worked on a small app using ngrx v.4 and the following is the git repo for the same git and the working example

like image 114
Rahul Singh Avatar answered Oct 23 '22 17:10

Rahul Singh