Main

Event Handlers in MVC: Publisher-Subscriber Pattern | JavaScript 🔥 | Lecture 275

Forkify App: Building a Modern Application LECTURE: 275 Event Handlers in MVC: Publisher-Subscriber Pattern | JavaScript 🔥 In the Model-View-Controller (MVC) pattern, the event handling is performed in the following sequence: View triggers the event - Controller triggers the model update - Model sends the notifications to pubsub pubsub - notifies all views about the event so that they can update the user screen. The publisher-subscriber pattern is a design pattern that allows you to create a one-to-many relationship between objects. In this pattern, there are two types of objects: publishers and subscribers. Publishers are responsible for publishing events when something happens, while subscribers are responsible for subscribing to those events and reacting accordingly. The publisher-subscriber pattern is also known as the observer pattern. Like | Subscribe | Share The Coding Classroom (⌐■_■)

The Coding Classroom

7 months ago

so let's now learn how we can listen for events and also handle events in or MVC architecture by using something called the publisher subscriber pattern and let's start by analyzing the code that we already have here so right now we are listening for the hash change and for the load events right here in the controller however that doesn't make a lot of sense does it because everything that is related to the Dom so to the view should really be inside of a view now maybe these two events here don'
t really look as if they have to do with the view so with the user interface but imagine that instead we would be handling a click event on some dumb element and so listening for that event should for sure go into the view and therefore we can say the same about these events here so in the end this has more to do with dom manipulation or with the Dom itself then actually with the controller and so therefore we need a way of putting this logic here into the recipe View however the Handler functio
n that we use to handle these events is actually this controller so it's this function that we have up here that is sitting inside of this controller module and so we have basically a problem here we don't want this code to be here so we want it to be in The View but in this code we need this controller function which is here in this module and of course we don't want to put this function in The View and so let's now think about how we could solve this problem and recapping everything that I jus
t said before we can basically say that we want to handle events in the controller because otherwise we would have application logic in the view and of course we don't want that but on the other hand we want to listen for events in the view because otherwise we would need Dom elements in a controller and we would basically have presentation logic in a controller which would be wrong in or MVC implementation so essentially event listeners should be attached to Dom elements in the view but the eve
nts should then be handled by controller functions that live in the controller module and so if you take a look at this small diagram that is just a part of the architecture diagram that we already saw before so here we have the control recipes function in the controller and we have a special method in the view which is called add Handler render now we might think that it is very easy to connect these two functions because why not simply call the control recipes function right from The View when
ever an event occurs well that's actually not possible because in the way we set up the architecture The View does not know anything about the controller so it doesn't import the controller and so we can't call any of the functions that are in the controller from The View so it only works the other way around and therefore it's more complex than this but fortunately there is a good solution and this solution is called the publisher subscriber design pattern and by the way design patterns in prog
ramming are basically just standard solutions to certain kinds of problems so in the publisher subscriber pattern we have a publisher which is some code that knows when to react and in this case that's going to be the add Handler render function because it will contain the add event listener method and therefore it will know when to react to the event now on the other hand we have a subscriber which is code that actually wants to react so this is the code that should actually be executed when th
e event happens and in this case that is the control recipes function that we already have in our controller and remember that the publisher does not know yet that the subscriber even exists because that subscriber is in the controller that the view cannot access okay but now finally comes the solution to the problem so the solution is that we can now subscribe to the publisher by passing in the subscriber function as an argument now in practice that means that as soon as the program loads the i
nit function is called which in turn immediately calls the add Handler render function from The View and that is possible remember because the controller does in fact import both the view and the model right now anyway as we call add Handler render we pass in or control recipes function as an argument so essentially we subscribe control recipes to add Handler render and so at this point the two functions are basically finally connected and so now add Handler render listings for events using the
add event listener method as always and then as soon as the event actually happens the control recipes function will be called as the Callback function of add event listener or in other words as soon as the publisher publishes an event the subscriber will get called alright and this is how we Implement event listeners and event handlers in the MVC architecture so this will allow us to keep the Handler in the controller and The Listener in the view and by that keeping everything nicely separated
so in summary the Handler subscribes to the publisher which is the listener in this case and then as the publisher publishes an event the subscriber is executed and if you want to think even deeper about this and are really interested in this then notice how there is actually a profound difference between a certain arbitrary like function a simply calling function B directly and function a receiving function b as an input in order to then call that input function so this is all about control in
the first scenario function a is in control however in the second scenario function a has no control so it simply has to execute whatever function it receives so if you want reflect a little bit on that and see that this is exactly what the publisher subscriber pattern is actually all about but anyway leaving that theory aside now let's go back to our code and Implement all of this and so with everything we just learned about the publisher subscriber pattern actually now implementing it should b
e the easiest part right so let's simply grab this code so cutting it actually and then here we will create a new method and let's just put it somewhere let's say here and so this will be our add Handler render method that we just talked about so add Handler render because this is going to be for rendering the recipe right at the beginning right and then this method which remember is the publisher basically needs to get access to the subscriber and so that in this case is the Handler function al
l right and so then we can simply paste that in here and then here of course we don't know about control recipes but we know about the Handler and so that's actually it for this function so of course it is not a private method because it needs to be part of the public API of this object so that we can then call it in the controller right and so let's actually do that now so we can get rid of this now and we will want to do this right in the beginning so let's create an init function here actuall
y like this and then we simply call it right at the beginning so only once and actually we could simply put all the code also here in the global scope but I think it's a bit cleaner to have a separate function for this that's recipe View dot add Handler render and so now we simply pass in control recipes and that's actually it with this we just implemented the publisher subscriber pattern for some reason we're still getting these errors here let's get rid of this alert here actually and simply d
o a console.log here okay but now let's go and see if this actually works we're still having our slow Network oh and here we have some problem apparently with the timeout so let's go uh quickly fix that here in the helpers so we saw that here it's at undefined like after undefined second so maybe this variable here doesn't exist so maybe it's kind of misspelled so let's see in the config well it looks right yeah it is the same well let's see again and so this apparently happens immediately for s
ome reason here so what if we put it back to some normal number well then it works which is very weird because this is in fact also 10. so let's see what we get here as we log timeout seconds oh but I'm actually right now seeing the problem so this is not helpers it is config so we are importing ourselves here so that was the problem let's put everything back and you see that now it is working even with the hash change event and so that means that we did now successfully implement the publisher
subscriber pattern okay and so let's quickly recap what exactly is happening here so we can also take a look at our final diagram here and here I actually have the event here in the controller because that is actually where it is handled and so I think that in this diagram this makes it a little bit easier to actually understand the flow of the program so anyway as we start the program so then the init function runs and it will then immediately run add Handler render right so it is this function
here and it's this function that is actually listening for events right here in the view where it actually makes sense now as we call this method here so in the controller we passed in the controller function or the Handler function that we want to get executed as soon as the event happens right and here we then receive that function as being called Handler and so that's what we then call as soon as the event happens right and so again in our diagram that's exactly what we have here so that's w
hy I have this dotted line here which stands for data flow so we are passing in the control recipe function as the Handler here and that is the whole reason why the method here is called add Handler render so because we are using it to in fact add a Handler function and in this case it is for rendering the recipe in the first place and then later on we will actually have other AD Handler methods okay and so it's crucial that you understand this logic here before you can move on any further in th
is project but I hope that with all this explanation this became all really clear and also obvious why we had to do it like this I mean of course we don't really have to do it so we are of course in charge of our own code but in order to correctly implement the MVC architecture this is the best way of doing it and so again then we can keep everything nicely separated into a model controller and view without any overlapping responsibilities all right so we have all of this structure here now nice
ly set up everything is nicely separated and so from now on all we have to do is to basically use this structure to implement all of the missing features of our application and so again really make sure that you understand everything that we did so far especially regarding the implementation of or architecture and then once you are really done with understanding that let's go straight to the next video

Comments