Extending the Event Emitter

🔥Get the COMPLETE Course (45% OFF - LIMITED TIME): programmingwit...
Subscribe for more videos:
/ @programmingwithmosh
Want to learn more from me? Check out my blog and courses:
programmingwith...
/ programmingwithmosh
/ moshhamedani

[@anamoly01]

This is under rated quality material. Good job 👏 we need more advanced tutorials like these.

[@jawamaster]

What a fantastic tutorial. Thank you very much!

[@scottchang182]

Perfect tutorial of the event emitter ;)

[@franciscoaloi5769]

Thanks for the clear explanations! Great job

[@ec4150-k4f]

Hi, great video, just a quick note. I assume on app.js we would no longer need to require the event emitter at all as this now handled by the logger class? Or am I missing something

[@bugs181]

You are correct. Looks like he just overlooked it.

[@weldonkipsang3332]

we still require the events emitter. Events log can never be generated without events emitter.In the tutorial we only got rid of events emitter instance and instead introduced a new class.The class is the one that emits/generates event logs to be listened to. The difference is that events emitter is now inside a class so that it can enable us to be able to have several classes with different event emitters which do not clash as we had seen in previous video. There is power in using class methods to encapsulate event emitters in its body. Inside body we use this.emit(arguments being captured).The class is then exported to app.js to be listened to

[@satadhi]

absolutely perfect !!

[@jared2224]

great explanation. thanks!

[@axedexango]

hello, it's possible to send a string to another file.js?
i'm trying to do but i can only use 2 file.js if i'm using a third one the code show emitter is not a constructor

[@sajedahmad8002]

Nice explaining

[@noormohammedshikalgar9974]

hey mosh hii , i want to know when is your nodejs course is comming im very exited for that please let me know...

[@qwarlockz8017]

Why would you add the messageLogged event outside the class? Shouldnt this be inside the class? Also, you are using "messageLogged" to define and to call the method. Should we make that a constant so we are not using "magic strings"?

[@weldonkipsang3332]

Logger () defined in app.js is an instance of class Logger defined in logger.js. On importation using require function, we capture two things which are very important. We import file and instance of the class in that file which was exported in module.exports. We then assign the class instance to an object named logger. The logger object will have /access all properties and functions defined in the Logger class. That mean it can read the emitted parameter "message logged" and any other function or property defined inside the class .We use logger.on function to read or listen to the parameters captured in a class using the instance of the class object. There is power in using classes and defining properties and functions inside it. Whenever you define properties and functions inside a class and you intend to use them elsewhere, remember to create an instance of the classname inorder to enable you to access the class properties and functions. In a scenario where you have more than one class defined in logger .js ,remember to export each class and create instances of each exported class in app.js

[@NullPointerHunter]

hey mosh ... good video ... thank you.
one note: imho you present a solution which is possible, but you should'nt use inheritance for this case. Extends means in this case 'logger is a emitter' ... normally this isn't the case. OK ... you can argument, you have now a LoggerEmitter ... But imho a better solution is a "has a" relationship. Logger is certainly only a example for extending event emitter ... I think in the most cases the "is a" releationship isn't the correct solution. If you use a "has a" relationship then your Logger is still a Logger and not a LoggerEmitter. And if you don't want to access the emitter property directly, you can wrap the emitter methods with own methods. Then you can name the methods to interact with the emitter better to your class usecase.

[@NullPointerHunter]

Hey Mosh ... thx for your answer.
Maybe I haven't catch the goal you want to reach. Instinctively I thought the principle "Composition over inheritance" is the better choice for your LoggerEmitter. I try to avoid inheritance in my daily work because of loose coupling. With inheritance I must use the Emitter methods from my LoggerEmitter. If I want to use EventEmitter v10 instead of v2 tomorrow, which has another API, I have to change my code in all places where I use the LoggerEmitter. If the LoggerEmitter encapsulate the Emitter I have to change only one file. But, you see, there is not only one truth. It depends what you want to do. Is there only one place you use your LoggerEmitter it isn't a problem. But if you write a fancy Logger module for your community of millions developer ... all have to check the own code for the new API. The same can occure if the Developer from EventEmitter stops his work and you want to use another new / better lib instead of EventEmitter (ok. bad example with EventEmitter ... google will always be available :)).
Is it worth to make a video with composition instead of inhertitance for the LoggerEmitter example?

[@uploadvoice]

@@NullPointerHunter makes sense

[@veliea5160]

why do "eventemitter"s r different on each module??

[@daniyelme9535]

Because, on each module it's a new instance (object) of the class. Continuing with his metaphor, they are twins.

[@sameerkulkarni8176]

this.emit() doesn't fire for some reason

[@forgotten3007]

Same, have you found a fix for that?

[@faithautumn5631]

#1st! HAPPY V DAYYYYY!!!!!!!!

[@itaybeyder9701]

Did not understand anything .. very complex tutorial and I bought the whole course....