Skip to main content
Loading Explore guides…
JavaScript OOP & Design Patterns · Acedra
Home
Explore
Computer Science
JavaScript OOP & Design Patterns
Sign in to save
Chat
If YouTube asks you to sign in, open the video on YouTube.
Watch on YouTube
Reload player
Transcript
99 segments
Copy
Hide video
0:00
This advanced JavaScript course is for developers who are struggling to really understand the benefits and complexity of object oriented programing. If you have read about design patterns, but you are maybe still not sure where to use them in your everyday work, or maybe you've started working with some modern projects and some frameworks and everything looks way too complex. Then this course is for you! And yes, if you use AI to help you code,
0:25
you absolutely need to know and understand what code AI is producing. So this course is very relevant to you. We will use real life examples from web applications. So no cars, no pizzas, no animals. And we will go over ten most useful design patterns and examples of how they are used in applications like Cms's, e-commerce platforms or popular frameworks. I'm Dalibor and I've been working as a developer for almost 20 years now on more than 200 products,
0:55
everything from single presentation sites over to e-commerce applications to mobile applications and some other internet portals. And I've built custom CMS. And custom frameworks. And everything we talk here comes from real life experience. When I started actively using design patterns myself, I remember that besides writing obviously better code, I started understanding complex functionality in frameworks and also my career basically took a noticeable improvement.
1:24
But most importantly, instead of being afraid of messing something up, I started feeling confident in my solutions. So why this course? Well, in JavaScript almost everything is an object. Yet writing flexible and maintainable code with effective objects, It's not easy at all in JavaScript. Design patterns are proven recipes for solving common objects or some sorry common problems in object oriented code. So by mastering them, you will go from just surviving
1:56
the way I did to designing a good solid architectures. So by the end of this course you will be able to organize robust communication between JavaScript objects with confidence. Recognize which pattern to use and when. Understand tradeoffs and avoid traps that make code messy and hard to refactor. Because your browser does not care how your code is written, but your colleagues and you your future self. Definitely do care about the code you write today.
2:24
Now, this course is not for beginners and I will not explain every possible functionality of JavaScript. And I will assume that you are familiar with JavaScript syntax already. However, I've kept the code as simple as possible so that we can only focus on actual design patterns. So you can follow this course and maybe pause and look up things that are new to you in the syntax, and maybe the way JavaScript works. Also, while this course focuses on vanilla JavaScript, the patterns you learn here
2:54
do apply to any language that supports object oriented programing. Anything from TypeScript to Python and maybe some pure backend languages like Java and C# and PHP. And I've structured this course to be the both a quick reference and also a deep dive. So we will go over the following ten design patterns in this order on the screen and in every module we will start a real life problem that you might face at work. Then we explain the design pattern, how it solves this issue,
3:22
and we code the solution together. And also we show how this pattern appears in popular frameworks. We do case studies of popular libraries and frameworks so that you can understand why things are built the way they are. Now, it took me a more than five months every evening basically to make this course and all videos in this, and all video files are completely free here on YouTube, where I will be releasing one module per month.
3:45
So just make sure to subscribe to get notified when a new course comes out. But there is a paid version on my website, ApplicablePrograming.com for my core superfans and people who really want to learn everything right now. It will not cost more than a coding book and you will get all modules available instantly. That is over 100 videos, about ten hours or something. You get all the source code that you can follow along. You get additional Skill-Builder modules, with video explanations
4:13
and code exercises so you can build these design patterns on your own. That’s actually, scientifically proven best way to learn. You get quizzes for each modules. You get a cheat sheet, you get access to closed community of students with direct access to me and other students to help you. If, somewhere, you get stuck in learning. So you basically get support for the set up and for learning and, you get to learn much quicker. And for a limited time, a six month professional IntelliJ license
4:47
for any JetBrains product. This is a courtesy of JetBrain to my students, so I cannot guarantee I will have unlimited number of licenses JetBrain is not sponsoring this video of this course, and they have nothing to do with this course. But they wanted to give students a professional license, so that is very nice of them. But if you do not need any of those extra features, first lesson on modules actually starts right here
5:10
and I hope you have as much fun learning as I had while filming this course. Good luck to you on your journey and happy coding!
5:20
The module design pattern is essential for any serious JavaScript application, and in essence, it helps us with code organization and a bit more. It makes it easy for us to encapsulate our code to make like small capsules or modules of code, so that the code from one module does not interfere with the code from some other module. So it is very important that we know what it is, but also understand problems that it solves how to build one and all problems that it can causes as well.
5:53
So you're probably very familiar with it. And as soon as I show you the code, you will be like “dah” isn't this obvious way to do it is in this the obvious and useful thing? And isn't it very clear how it works? Well, let's see why it exists first, then how it works and what exact problems does it solve. The typical example where this pattern helps, are operations where we have many methods with the same name like create, read, update, delete, also known as C.R.U.D. operations.
6:26
And we would have these operations for many entities. Many objects like product or user. We cannot just call them create and update as we do not know which entity are they referring to. So we have to name these functions, these methods, something like update user, delete user update product, delete product. And so on. But then we figure out that it's better to actually call them user update and user delete, etc. However, later we will have to change this
6:54
to User Admin update and User admin save etc. and this is where module pattern helps us with not only the easier naming, but also encapsulation, meaning that methods are separated in their own containers. To put it like that in their own well modules, so that everything related to manipulation of users is within the user module and everything for products into the product module. The module pattern is used in many different applications,
7:23
many different frameworks and it works best in a bit larger and a bit, let's call them, long term projects where we might be adding a lot of code and a lot of features in the future. So if you plan on your application growing in the future, you should consider splitting your code in modules. The biggest advantages of the module pattern are namespace management. It helps us avoiding that clutter the global scope by provide a namespace for our functions and our variables.
7:53
A namespace is simply a container like an object from our example, and it groups related code together so it doesn't conflict with other code in the global scope. Reusability. With modules, we can easily reuse code across different applications of our applications, or even between different projects. Code structure. It's much easier to work on specific functionality in a single file and just include that file where needed. Modules can be loaded directly from HTML files,
8:23
or they could be imported into other JavaScript files. This also makes the code much cleaner and easier to manage. We have scalability. When coding files are structured well, it is much easier for our application to grow because, we can just add new files and new modules when needed. Some disadvantages it has are Well, understanding the principles. If you're not familiar with concept at all, it might feel strange or unnatural
8:52
or overcomplicated to just split your code in multiple files and have it living in multiple different, places and having to think about it. But I guess this goes for any other patterns or any other things in code as well. There is also a risk of overhead. Again, if you're not careful, you can make a bunch of small files and make and make the application even more difficult to maintain than when you started. Sometimes a simple function works just fine, and you do not need an
9:21
entire module, so you need to be a judge if this is useful for your project size. Another thing to watch for is circular dependency. This is usually not a problem, but if it happens, boy oh boy is it difficult to track down. And it is a situation where two or more modules basically depend on each other causing potential runtime issues. So kind of in a circle, the first one depends on the other. We will go into details on that one. We will go into details on that one.
9:49
So modules in JavaScript are very useful. They provide an essential mechanism for encapsulating functionality, managing namespace and structuring application more effectively. And you will find modules in pretty much every application or framework. Let's look at the problem that the module pattern solves and some alternative solutions to that problem, but also maybe some disadvantages along the way. So here we have a simplified e-commerce functionality
10:16
where our users can, order something from our website. And then after the order has been created, we are going to calculate the shipping for it. Now, this is very simplified code. I have removed all business logic. There is no working with databases, with backup backends. Everything is mocked. So that we can only focus on how this design pattern works. That way you don't have to pick your brain about something or be surprised about
10:41
some, syntax or something in JavaScript that you never heard of before. So for us to sell something and then ship it to our customer, we obviously need some functionality. Like, create and then process and then update the order status. So far, so good. These three functions can get us along quite long. Good. And I can run this code here.
11:05
And if we look in our browser in our console, we can see that order has being created and the payment has been processed. And then it's been updated to paid. And this is basically this functionality here. So already created payment process. And then the order status updated. So far so good. But as mentioned at one point we need to make a shipment functionality which will also will process and update the shipping information. So somewhere in our code we need another process and another update.
11:36
Now the easiest way to do that is to just add these two functions here. You can just add another process and update, this time on the, shipping. However, if I were to run this code now we can see that there is a syntax error. And that is obviously. Because these names are already taken. So the update cannot be defined two times. And the same with the process. Now the easiest way to fix this is to obviously call them processShipping. Or shipment.
12:10
Nobody is that stupid to use the same name twice. You would think. And now everything works. The order is being created, processed and then the shipping has been updated for the order. Now, I'm sure you might think, well, this is an easy solution, but what if at one point we need to add the functionality for managing users, managing user profiles? We also have the same problem. We need to rename the create and update and process and things like that.
12:40
So maybe here we should change this to be createOrder.
12:47
And then the same with processUpdate so that there is no, collision. Now we are sure that when we refresh the page, there will be no collision. When we create user. Now, if I were to call here something with update, we see that we get updateOrder, updateShipment, updateRate, updateShipping updateUser, updateUserProfile, etc. etc. so it's better instead of calling it update to just go back and to change this to the orderCreate. And orderProcess
13:25
OrderUpdate. And we change that in our application. Now, we've been doing quite a lot of coding, and yet we haven't made any functionality. Doing this and maintaining code like this works, but we can still very soon end up using all possible combinations of names, trying to avoid conflict like createUserAdmin and then createUser or createGuest and then createUserLoggedOut, etc., etc.. You see the problem here. this is not a sustainable solutions, But also other developers in our team
14:00
might be using different naming which makes sense for them, but makes life unnecessarily difficult for everybody in the team. So we could use here object literals. Like this. And it has a lot of benefits when it comes to, organization. This also looks much better. It's much easier to see and follow. And it looks cleaner. And all functions and methods are now in the same place. And you might think, well, this is good enough. Why don't we continue with that?
14:28
Because we have create process and update. And the main reason is that still there is missing a concept of encapsulation, Meaning that this data that I put here, the order data here, if we would just to say at one point orderManager.
14:46
OrderData and let's say name. And if we just clean this name to empty space, this would change in the entire application. I even got the autocomplete from the editor. That's great, because we now get that help. However, if I were to update this data and, Let's say that I get this data somewhere like the customerData right? And then I update this customerData to, empty. If I would, to use this orderManager some other place. So not this customerData, but orderManager and console.log() this
15:23
It would actually output null here. If you look at the console, there is an empty line here. Outputting null value. And that is because we have, accidentally overwritten the orderManager data. Internal data with some external variable. And this happens more often than you would think. And this is where modules would help us prevent that, making our application much more robust. The second issue here is that as I shown, everything is exposed to everybody.
15:53
While the code is decently organized, this order data is available here to change and to do something with it. And also when we do the update of the order or calculate shipping, for example, there will be a lot of internal, functionality here that's relatable or that's relevant only for the shipping and not for using outside. And our IDE would still here suggest all of those private methods. If I were to make something like privateInternal.
16:26
Our IDE would still suggest us here The order manager. We can still access this privateInternal and it will work just fine. It will call it. And there is no mechanism preventing us from using some internal functionality here. And that is part of the encapsulation or control or controlling access, because we only want to expose those functions and those methods and variables that are relevant for our users of this library. And finally, since this is one object here has to be in one file,
16:58
this file would grow to be just larger and larger as our application. Grows, we could split this into multiple objects and multiple functions, but then you kind of making unnecessary compromises. Also, at the end, each and every file needs to be included in our application in every page. So we could or we would risk missing some dependencies or some functionality somewhere along the way. But I want you to pause here and to look at this code and think, how would you solve this
17:28
problem of encapsulation and this problem of name spacing. and then we are going to look at how modules can help us solve this.
17:37
Let's go over one example of how module design pattern helps us with all those problems, like encapsulation and namespaces with naming and few other things. So in this example I have a code that works with some content. This could be a post on a web page or maybe a forum article. And here we have methods like createPost, delete And probably update. But then we also have create comment delete comment, and some internal functionality like analytics create tracking and delete tracking.
18:09
And this looks just fine. And why would we complicate this with modules for now? Well apart from the fact that all our methods start with create and delete and some of them start with tracking, create and tracking delete, which after a while will bring us to having tens or maybe hundreds of same methods starting the same, but having nuances, in their naming like createUser, createAdminUser, createGuestUser, createUserEditor etc. which in the very least will make our autocomplete
18:44
in code editors unusable when this application grows because it becomes increasingly more difficult to maintain. Now we could split this in multiple files. And don't have to look at them. But the problem is still there that the names have to be unique. And we also have to include each and every file in the entire application that we use. So here is where we introduce modules. And what modules do is they actually group this functionality together. And this way we can use these modules
19:14
anywhere in our application and call them only when we need them. So this module does not have to be included each and every time. So we can then just call our methods from our modules directly, which now allows us to know basically which module has these different methods, which is actually a solution to our naming problem. Right. Because now we can have the same methods create delete, create, delete. As long as they're in different modules they could have the same name.
19:47
So this is what namespace is. It allows the same name for methods but in different namespace. We can also move these methods into different files. So that we have better file organization. And only include the files that we are actually using. That waz we don't care if we have tens or hundreds or tens of thousands files. We just import the one that we actually need. But most importantly, these modules are now fully encapsulated, meaning that well, post module is completely isolated
20:21
from the comment module and from the analytics module. So they don't care about each other and they could do their own functionality inside. And all relevant methods are inside corresponding module. And also they cannot interact by accident calling some other methods that they're not supposed to.
20:39
And even by using this export statement we can actually control what are we going to actually export from the module. So this is a private function Now because it's not accessible from anywhere except from this module. Right. It's not exported here. We could have additional function here like for this clean up. And if it's not explicitly exported from the module. Then using it somewhere else will actually throw an error. Because the code cannot access it.
21:07
And this also helps us a lot with reusability of our application, because we can actually copy these modules to another project or another application that we might have. And also, since these modules are now self-contained and have everything they need, they should just work fine in different application with little to no modification. At the same time, our application becomes much more scalable because we can add as many modules as we need without having to worry
21:36
that our application will become too slow for the users, or that the page will take too long to load. That is because these modules are imported here only when we actually need them in the application. Now, please note that this way of writing modules is only one possible way, and they are not definition of this pattern. The patterns are not about the exact code syntax as we've mentioned several times. They're much more about the organization of code or data flow.
22:06
For example, this could be set as functions here, so that we just export the functions directly. And when we import them then we can do. Renaming so that we don't have conflicts here. But that is up to preference. And this is something that we will do in the skill build module later because remember watching is understanding but actually doing is learning. So for the end here, I wanted to mention the circular dependency that we mentioned before, because this is
22:34
something that could make your life a bit difficult if you are not aware of it. And what circle dependency is, is actually when one module depends on the another module that actually depends on the very first module. So in our examples the comment module would use some analytics. And the analytics would also use something from the comment module. And this is probably not the best example from out there. But at the same time this is almost resolved using ES6 ES6 modules.
23:08
But it's not completely eliminated. So it's something to be aware of. So if you have to resolve this you would use some mediator. So a third module that would then include these two modules. And then you can just call from that one. And that mediator will do this complex task and take them outside of that conflicting situation. And there are also tools that help with this, like Webpack or require JS and probably many others. So look into them if you run into this problem.
23:39
But just wanted to show here what the circular dependency is. So anyway, module pattern helps with namespaces, file organization, encapsulation, reusability, scalability. And even with access control. But you kind of have to be a bit aware of circular dependency and file complexity. If you have really many modules.
24:00
Let's change our code example so that it follows module pattern. What we need in essence for modules is to create two files. And I've created this folder named modules. And in it we are going to create two new files. One will be Order And another will be shipping. Now all we need to do is move this functionality. I will remove this from here. We need to move all the functionality that is for the order inside the order file. And what we need to do is to export something from this file.
24:31
To tell to JavaScript that this is a module. We are going to export them from this file and then import them into the main app file. One way of doing that is as we did before, we can create a. Object.
24:45
So this would be export. Const orderModule. And for each of these functions I'm going to make a property Create. And one for process. These could be now nameless functions. And then finally one property for the update. So this is pretty much ready. We just need to import this order module from the main application file. And that is as easy as saying import. which is the orderModule. From order. We need to put .js here. And with a bit of luck if we run this file.
25:22
There is a problem that the order process is not defined. And that is because we are just, calling the old functions. Now we need to change this. Then instead of, orderProcess and orderCreate, we are going to call our orderModule.
25:38
And then we are going to create the Or sorry called the create property on that one. We will do the same here for, process. And the same for orderUpdate. we can see that we still have this as it was before. So there is orders being created and the payment is processed. And then it's updated to paid. And then the shipping has been set to shipping, even though the shipping is still the old way as we are doing it here in the code. But that's fine. We can just do the same for the processShipping
26:11
Now in the shipping we are going to move these two functions.
26:16
And let's do the same export constant
26:20
shippingModule. And let's just make two properties. One is process.
26:26
And another property. Being update. Then in our app, instead of processShipment, we just import another. Shipping module. From shipping. And then use the shippingModule as our initiator for the process. Here. And if we test it, it should work, as it did before. Now, using modules here, if you can see, we have basically solved two problems so far. Maybe even more. But the first one is name spacing. And the second one is encapsulation.
26:57
So name spacing means that naming of these methods it's much cleaner. So there is create process and update. And there is process. And we could even have another shippingModule.update. And if we check in the code sure enough tracking has been updated. So what this means now is that we can have. Multiple methods with the same name, kind of the same functions with the same name. So it could be update and process. But since ones is the first one is on the orderModule,
27:27
it will never conflict with the shippingModule, right? And this way our projects can grow as much as it needs because it doesn't matter. We just add another file or we just expand this, shippingModule or orderModule. Which also brings us to the second point. And that's encapsulation. We now have everything that is related to the order into the orderModule. And then we have everything obviously related to shipping inside the shippingModule.
27:54
So if we want to change something and we want to update something or maybe add another property, change how the shipping is done, how the updating is done, it's very easy. We know exactly where to look for and we can just change that and small thing. And that improves our single responsibility principle, which is the first of S.O.L.I.D. principles, meaning that there is only one reason for this object to change. And you might think, well, my application will never grow. It's fine as it is now.
28:25
You can just add another file and move everything here. But you do want your project to grow. Actually, you want many, many users on it. And one day you will not be able to manage it all. So you want to hire multiple programmers or to get help from multiple programmers to help you. And how will they work where all the logic is one to the file, right? This is why we need the modules. Remember our problem of anonymizing the data and it being changed globally.
28:54
So here in the private module that I can show you how this works now. here we can, before we export, or after we export. But as long as we don't export, we can just move our code. That was private. Let's say there was some order data, that is talking about, who the person ordering is. And now this data could be used here. I can just log it to see that we have it. We can see here the order data. So it is accessible from our module here. However, if I try from the app to, do the same.
29:39
This will not work because there is no reference to to this orderData. And if I try to import it. From the order.js We can see that it cannot find the orderData because it's not been exported. So it has to be exported for us to access it. And that's the key that is this control that we have. So unless we say that it's exported from this module, it's accessible only to this module. We could, do something like getOrderData the data make a getter here.
30:15
And then we can return it. And then instead of just using the order data, we can say orderModule
30:23
getOrderData()
30:27
Let me just remove this import because it's not valid.
30:31
Now we can still get that orderData outside from the app.js here. But more importantly, instead of just exporting it here.
30:41
Remember our problem of manipulating the data? Get order data. If we now change this, anonymize this data and run it from the browser, it will still be anonymized. however, there is a little trick that we can do. And that is that in the get order data we can manipulate, this is as needed. So we can just, use the spread operator to make a new object.
31:05
So that when we call it again, we just do the same.
31:09
And now this other variable will not be un anonymized. And that is because the first one is a local variable in the app line 19. And the second one is in app line 24.
31:26
Meaning that even though we are getting the order data, this actual values that are here are kept safe to this local space, to this capsule. But it's important that as a developers, we know many solutions. And there ups and downs and there are advantages and disadvantages so that we can choose the correct one. With the module, you kind of get into, a lot of files, a lot of complicated things for simple things, if you can solve it with simple solution, don't complicated.
31:55
But just to summarize, we have fixed name spacing, file organization name spacing, in a sense that we can have the same name for different functions in different modules. Encapsulation and data control where we can actually have private data here. And also we have increased reusability in a way that we can just copy one of these modules. And copy them and use them in another application. But also we have kind of solved the scalability, or enhanced scalability so that our application can grow,
32:30
much better now because everything is in its own file, in its own place.
32:35
Let's have a case study where we look at several open source applications like CMS, blogs, libraries, and see how they are using these design patterns. So for the module pattern, I've found this, Strapi which is a open source headless CMS. So it's a CMS without the front end, only the back end. And that way we can make front end using whatever we wish, whichever library we want. And this one also uses a TypeScript. But in the other examples
33:04
there is pure, JavaScript as well, like here in the get started example where they import relevant modules, like other component libraries
33:14
from React and button, but they also then export them from here or in this case the default export which some configuration and some bootstrapping of the application so that the main application can use this, admin part here. Or for example, this other admin example here. So when we work with this CMS we will not edit all JavaScript directly. We can just reuse these modules. And this configuration and this setup. And then we can do something with these modules
33:42
and that this module will be picked up as mentioned by main application, and boot it up and configure properly, for you to use. But you have some flexibility in adjusting these configurations like here in this theme file where they are configuring, menus and logos and things like that so you can change them yourself. The second example is this Decap, also CMS, but this time, this one has the front end. So it's not headless. It has a head.
34:11
It stores content statically in the git repository, which I think is quite cool. There is no database, for this, for content, which means that it's very fast. And in their source here in the scripts folder. And this is how this stripe it looks like for by the way, you can, go in and change, play with the content. But in their source there is this publish, this JS file, and we can see how there are importing modules. This time they're using the required because this is a Node.js application.
34:42
But same is visible in this, externals.js file, or maybe in the webpack configuration where they're importing different modules from, different plugins in this case. And we can see how they are using the module pattern, even though this is a backend. So it's used a bit differently with Node.js. And the next one is probably a library that you probably used before. And that is the react library. It uses module pattern for pretty much everything.
35:10
And even components are kinda “modules” on their own. We can see that, for example, this dangerfile here, it requires quite a lot of other components and other modules. And we can see that in many other places like in this flow, for example, where they require some other, components or some other modules to be used in different files. Because if you think about it, it would be impossible to organize all these files and all these folders had they not been split into modules.
35:44
So the module pattern is very widely used in many applications in libraries. And even though we might be familiar with it and use it on a daily basis, it's good to know and go a bit deeper to understand what it solves and how it actually works.
36:00
Let's summarize the module pattern. Because according to best teaching practices, it is important that you try yourself to think about the answers first. You also have the worksheet that you can download with the source code. You can just print it out or fill it digitally. And now it's a good time to use it. To summarize this design pattern to solidify the knowledge. So first do you remember what problem does module pattern solves? We talked that it is dealing with code and component structure.
36:29
So it is used to organize and structure components of a system. So that we can manage complex applications a bit easier. Now main advantages. Do you remember which one are do you remember these. We said that is working with encapsulation
36:49
that also organization of the code. The module pattern allows for clear separation of concerns by encapsulating relevant functionality together, usually in one file. Maybe this separation allows for private and public access levels as well, to a certain code, to a certain method, so that not everything is exposed to the consumers of our code. It also allows for namespacing. We talked about the problem,
37:21
so that we can have shorter and relevant names, of our method, so that we can avoid conflicts with other modules might have exact same names. We also talked about scalability and reusability. Right. Meaning that code is very well organized. It is much easier to scale the application, like adding new code without our files becoming gigantic and difficult to work with. Also, we can very easily reuse our code by just copying these modules into maybe new applications. It is just one file right?
37:54
Now some of the disadvantages cons or maybe dangers are we mentioned the circular if you remember what dependency
38:04
circular dependency where two modules could be depending on each other, thus going in a circle, right. Although this is mostly resolved with ES6, you still have to be aware of it. But the second thing and, problem that we talked about, which is probably relevant* for every design pattern, I name it all the time, is complexity. Again, it is probably true for a majority of design patterns, maybe everything in life. But, it means that we should not create files
38:37
and create modules where it does not make sense and just make our life more difficult because some bold guy on YouTube told you to do so. The module design pattern is widely spread and it is used in many frameworks and many applications, especially in a bit more complex ones like majority of pattern, my guess. So if you want or expect your application to grow, maybe have more people working on it in a future, you should probably consider using modules upfront
39:04
or at least some other modular approach like components or similar. Now continue to the skill builder part to solidify your knowledge about module pattern even more.
39:15
An important part of this course, are some skill building exercises here in the download source code. You can find some of the tasks that you can practice on your own. Because remember - watching is understanding and actually doing is learning. You actually want to learn. So you want to use to do these exercises on your own. So you want to use to do these exercises on your own. Don't use ChatGPT Don't Google for other things. You can watch me talk about riding a bicycle as much as you wish,
39:44
but you have to sit down and ride the bicycle yourself in order to learn. So what we have here is that there are four functions. So what we have here is that there are four functions. A two are for admin user and two are for the products. And your first task is to split this obviously into two files into modules, and then import them here and just use them as as I've shown in the previous example You don't have to use the modules,
40:08
if you don't like, I will use in this solution here that I will show you later. I will actually just export the raw functions and then I will use them here without the module. So in some cases that's good enough. You can just run this index file by using the live server. I'm using the IntelliJ here, Webstorm. Webstorm. But you can achieve the same, part using the Visual Studio Code. And I have a video on showing you how to do this. But in this skill builder, you can see that we are creating
40:38
and updating user, also creating and updating a product. And you just need to, refactor a code to use modules here. Now this is relatively easy task just to get started. If you do get stuck, go to the go If you do get stuck, go to the go to the community section in the website, in the course website, and check examples that other students might have shared before you, and then try to use a few minutes to solve it yourself and see how it goes.
41:04
So let's look at one way of solving this task using the module design pattern. And I will not write the code. I will just show you how I did it because it's relatively simple. So here in the solution I've created two files here. And if we look at the products admin you can just export the function directly as I mentioned, just to do this a bit differently. We export create and then we export update. However still if we import it here, we have to import it as a userAdmin.
41:35
Or you can actually import functions yourself. But then if you import two with the same name you will get a error, meaning that you have to give them alias. And that's a fine exercise to do. I've done it here and I've imported everything, and then put it into an object here on the fly so that I can just run userAdmin.create and, update in the same for productAdmin, create and update. You are more than welcome to share your solution if it's different in the community section for this course,
42:04
even if you are first student of the course, remember sharing is caring. Also be professional. And respectful. We are all here to learn so there are no stupid solutions. There are no stupid questions. Feel free to reach out to other students if you have any problem. Also, check out the source code for the second task, that you can practice on. Even though there is no video for every possible task, they should be relatively easy and should enforce the learned knowledge. Good job so far.
Here to help you learn
Sign in to keep a private conversation with your course tutor.
Ask me anything about the material…
Sign in to chat