 So, so far from morning we have been looking at various different ways to improvise your code quality. We started off with Jai having how to manage large repositories and then we had Rajsekar talking about how to transform code and now we had some techniques to reduce your errors, typical errors and now we have we have Pulkit Kashyap from Wingify and he's going to talk about you know the essential next which is about using some of the best design patterns from the industry, a few things which will help your code become modular and more maintainable and things like that so over to you Pulkit. Thanks. So before starting off am I like audible at the back can I just confirm. So hi my name is Pulkit and I work as a software engineer at Wingify and apart from work I'm also you know I'm an active contributor at FOSS Asia. So I mean if you actually know what is FOSS Asia like for those of you don't know I should definitely check it out because it is an awesome open-source community. So coming back to my talk so as I said I work on a product which relies heavily on the smooth functioning of a library and you know I've been working on that library for a while now and while working I realized the importance of modularization of code base and I consciously decided to name my talk breakdown to take down because I believe that breaking down your code base into individual modules will help you take down a lot of problems. So let's begin. So the first question that comes to our mind when we talk about modularization is like why should we focus on this? Why should we even care about modularization of code base? So it is a well-known fact among developers that you can't write your entire code in one file. Moreover if let's suppose a new person comes in to contribute to your code base it becomes difficult for him to contribute as well. If the code is not divided properly and to add more thoughts to that delegation of responsibilities is very important and also modularization or independent modules they kind of provide certain kind of abstraction to your code and also a very important point debugging becomes very easy like I've experienced this personally and debugging becomes very very easy if you have a well-defined modules. So this is why I think we should focus on modularization. So now what you see is a very basic interface a very trivial example I would say this is an interface that you might have seen in any web app or any kind of heteroid app. So what you see on the left are some tabs profile password devices and you can have number of tabs there and on the right side is the heading and let's say is the corresponding body. So when you click on profile it renders heading as profile and the corresponding body. Similarly for password devices and the other tabs but how can modules come to our help here although this is a very trivial or a basic example but we'll still observe how modules can come to our help here. So what you see now is the common part of the previous slide the common extraction heading in subheading. So how about if I make a module an independent module that takes in two parameters heading and body and re-renders are different UI a very different feel every time. So if I click on profile then it would render the heading as profile and just reusing the same code it would render a profile and the corresponding body and similarly if I keep click on password it would render the things which are provided as a parameter. Similarly for devices others and you can have a number of tabs just the same code will take care of all the UI it would re-render the a different UI a different feel every time while you're using the same code. So now what you see and also the people who work with React or similar front-end frameworks would be able to relate to this better. So this is a piece of code which takes in two parameters heading and children and what it does is it renders according to that. So what you observe is using the same code base using the same code we render a very different UI or UX every time. So you just have to pass on the parameters and this will act up accordingly it has nothing to do with other other code you have this is a very independent code and you just have to care about the parameters you provide and it would take care of the rest. So we observe that even though it's a very small example but modules come to our help here as well. So what makes our modules meaningful? I strongly believe that just making modules just for the sake of doing it is not enough. You have to make your modules meaningful and what I mean by meaningful here is so there are four parameters or four pillars I believe that make your modules meaningful. So let's go through them one by one. The first in the very important parameter is reusability of code. So I'll give you an example. So as I said I work on a library so it is often the case that we have to detach or attach events to the document or the HTML elements or whatever is available on the page. So what we have done is we've made a module called as events manager. So what it does is it adds the event listener using jQuery without jQuery and in a lot of cases and also it removes the event whenever we tell it to. So it doesn't matter how many repositories we have we might have 10 or 11 repositories use the same code whenever we have to attach or detach an event we use the same events manager code. We just tell it to attach and it does that does the work for you. So reusability is very important and also you know if someone new comes in and contributes to your code base and if he has to add event listeners or remove event listeners. Now he doesn't have to care about that. All he's got to do is call your events manager and it'll do the work for you. So reusability is a very very important factor. Another factor is stress worthy. So how do you make your module stress worthy? Also for now just settle down with this that your modules have to be trustworthy and I'll come to this later how we can make our module stress worthy less coupling. So coupling here what I mean by coupling here is how your modules how much your modules are dependent on each other. See the higher is the coupling the more unmanageable is your code. But although I also agree that at granular level your modules have to extend some basic functionalities like this has to be some basic code that your modules have to use. So they have to extend kind of that basic functionality but it is generally the desire desirable case that you're there should be as less coupling as possible because even for the new person contributing it becomes easier and it is more manageable. The next in the very important point is independent. Now coupling an independent might seem overlapping here. But what I mean by independent is let's suppose your application has 10 components and if one or two of them go down. So they should not take your entire application down. At least your application should be capable enough to just just to provide you a basic functionality even if one or two component one or two modules even go down. So these are the four four factors which I think are really important to provide many to your modules. So as I mentioned how your modules can be made trustworthy if they can be made trustworthy through writing end to end and unit test cases for assurance and reliability. So I'll explain through an example what happened with Nemo's I had to fix a bug. So I wrote the code and just like most of the developers think I didn't write the test case thinking that I should be doing something more which is productive other than writing test cases. So what happened was it went on to the QA anybody here who's who's a QA would understand the importance of test cases there. So the QA discovered a bug and I would say it was a very, very basic bug and should have been caught at the developer's end. So as a developer what what is your job? Your job is to make it difficult for the QA to catch that bug. But that was a very basic thing and I should have caught that bug from my end. And what if I had I had written test cases at that point of time. So all this time the code goes from developer to the QA it's called it's called dev handoff. All this time was based won't say wasted but this would have been avoided if I would have written test cases for that particular bug. All this time would have been avoided. Also not just saving time it test cases also make you sure about regression. So what I what I mean by regression here is let's suppose you've written something you've written some code in the past and you're adding a new feature or a new person is contributing to your project he has to add some new features. So how do you make sure that the existing functionality does not break. So you do that with test cases test cases like checkboxes. So let's assume if you have 1020 test cases or they are like 10 or 20 checkboxes like if those checkboxes are take at least you're sure that the functionality you've provided earlier or you've written earlier is going to work. Although I also agree that you cannot be 100% sure that everything is going to work as it is. But there's a sense of security that what I've written in the past it's at least going to work when I take it live. And also if you have test cases it becomes easier to add new features because you're sure about the code you've written. And yeah, so end to end test cases is when you write. So let's assume I have a library and I have to test it as a whole. So this is when I write end to end test cases I want to test the application as a whole and unit test cases is when you want to test your modules as independent entities unit test cases have nothing to do with the outside world they just test that particular module. So this is when you write unit test cases and end to end test cases. So next I come to patterns for modular architecture. So these are the patterns which I've worked on or I would say the most commonly used patterns. So the first pattern is facade pattern. So it is a pattern which provides a very high level interface while hiding the underlying complexity. Let's I'll go through it with an example. So what you see now is our three functions for I for Chrome and get mutation observer. So just a little heads up mutation observer is something which was introduced in the later versions of I and it is available in Chrome since a long time. And it is available by different a variable name in I and Chrome. So we have two different variable names to access mutation observers when you have to do it in two different browsers which in this case is I and Chrome. So what happens here is what you give to the end user here is the get mutation observer. So you tell the user that you call this function and you get the correct mutation observer variable no matter on what browser you're using. So what do you see the end user doesn't care about the internal implementation. And that is the ideal case like right. You don't want the end user to care about the technical implementation. You just want to give him the end product which gives the result. So whenever the user calls the get mutation observer functions what happens is it automatically judges which browser you're working on and then pulls out your mutation observer and gives it back. So although it's a very trivial example but this depicts of a Kate pattern works. It works around the same ideology of hiding the internal implementation and providing to the user the important part. And it also provides a certain kind of abstraction to your code base. So next we come to mediator pattern mediator pattern or most of you might know it as or some of you might know it as pub sub pattern or it's called as pub like a publisher subscriber model. So think of it as YouTube like I've subscribed to a YouTube channel when that particular channel publishes something I get that video because I've subscribed to it and the people who haven't subscribed would not get that video. So this is the like the basic ideology behind this pattern. So what happens here is module to one two and three they can be either publishers or subscribers while the mediator is both a publisher and a subscriber. So what happens here is module to module one send some data to the mediator through an event because the mediator has subscribed to the event thrown by module one it sends some data since the mediator has subscribed to the events it gets that data and and then what it does is it does some kind of processing and then it publishes the data to which module two and module three have subscribed. So they get module two uses data for some kind of processing and module three uses this data for some kind of server logging or whatever. So how it happens is module two and three have subscribed to the event thrown by the mediator. So accordingly they get that data and all this communication that that is happening here is through the by the use of events and all these modules don't really care or know about their existence. So this works on the basis of events and they catch the events they've subscribed to like if mediator throws out 10 kinds of events. So what happens is module two and module three have to answer to or cater to only those events to which they have subscribed. So this is how mediator pattern works it works on the basis of events. Coming to the advantages as I mentioned these modules don't know about their existence they communicate by events. So there's obviously less coupling and with less coupling comes independent modules and one day disadvantage or drawback if I have to mention is since it is based on events and facade pattern packet is not based on events there's an obvious performance drop in case of this mediator pattern and if I come to when how should I decide when should I use mediator pattern or the other pattern the mediator if let's suppose I'm making a library and I wanted to be very extensible I want people to be able to easily add plugins I'll give them the name of the events and I'll tell them that my library has already subscribed just do your data processing throw your events and my library would take care of the rest and I don't want the end user or the person who's working on the plugin to go too much into the technical details. So this is this is where you use mediator pattern and you know libraries like jquery, AMD modules in common they're based out of the facade pattern so that was my time guys thank you and that is my GitHub user name and my Twitter handle would love to connect to you guys over to you. Hey thank you Kuldeep, Apulkit sorry, somehow I'm always remembering your name as Kuldeep. Alright, any questions? You talked about mediator pattern is it something like event bus? Sorry? So this mediator pattern is it something like event bus? Yeah if you go through PubSum model it's easily available so it is totally event based. So I mean we can use to like in your framework, JS framework like you can use to for that. What you would want to use it with react? See it depends on the use case there is as I mentioned there is an obvious performance with mediator pattern so and you want to use that in cases where you wanted to be like very independent and the other pattern is you use when you want to hide the implementation so it depends on your use case it completely depends on the use case. If you want your modules to be like completely independent less coupling then you should go for mediator pattern. Any other questions? Can I just go over the facet quickly one more facet pattern? So start batting and talking about this so have you used jQuery before? Yeah. So what happens with jQuery is you directly call the functions and you don't care about the internal implementation because it is written in jQuery in some form so it hides the internal implementation so if you if you worked with immediately in both functions right so it let's suppose it returns something and it has some kind of variables that are private to it so this is how it works like you're returning something which is available to the end user while you're still hiding some kind of implementation keeping it private so this is when you okay okay so what happens here is the function yeah so the function automatically judges the browser under the UA and then it gives back the mutation of the variable available on that particular browser also these are the patterns which I worked on so far particularly on the first one so I wanted to explain these only.