 So, hello, I am Kapil Varma, I am a developer, entrepreneur based in Delhi. I am happy that A.T.Line is my internet link. Back in Delhi, I am involved with two startups, Muse Jam and Blazing Train. Muse Jam is a platform for live music industry. Its version 1 is out and we check it out. And we have just started with the version 2. Problem is I don't know this one, we will be out of that. I am pretty confident that it will do a lot of awesome stuff. And Blazing Train is a startup focused on visiting solutions for enterprise companies. We have one product out right now, it is a warehouse management system which has been used in two warehouses in Delhi, near Delhi actually. And it's refined, it's also in its final status, this product and it's refined. Ask for the feedback from the operators of the warehouses. So, my history is angular. I am a front-end developer by accident. I mainly code on the server side, I mainly deal with data, building extensions to warrants, better ways to work with data and servers scaling and etc. But it turns out that all the things are important in programming good APIs like dependency mitigation for example. Design parties again, kind of a code very well to angular development. And I have been working with for a year and I have done a lot of stuff using angular. So angular and client-side architecture. This is how I see client-side JavaScript applications. They need to interact with several different components like your application API, some of the external APIs. The window through which the user interacts with your application and the UI regard. That's pain in the ass to be willing, but it kind of provides a thing that provides a UI for your application. And client-side JavaScript application is seen this state data with all these things. The architecture of this application should be such that that according to, suppose it's in state B and then it interacts with any of these other components. And according to both interactions, it reaches state B and then it should behave in that state B in such a manner that its history basically should not affect its behavior in state B. What I'm trying to say is that this client-side applications kind of have a heavy requirement of being stateless. And a simple to put in more simple terms of what I mean is that basically suppose a user enters URL slash 4 in that bar. And that should result in the state of the application that results. That comes out when the user enters URL slash 4 in the URL bar. Should be the same as state achieved when the user has started the application from URL slash 4 and through several different actions has made his way to URL slash 4. That was clear. So, and this is what I'm trying to achieve before I end up using my account, which I found to be not enough for client-side apps. And then using Backbone. The chart went through their own approach. And before I end up resorted to not using famous at all, I start with Rigmar.js, jquery and Backbone argument for most of the things. And our class is completely in JavaScript. And the second part actually helped me a lot with writing client-side JavaScript and also the node stuff. This is actually a ring-to-ring talk which discusses this type of approach of JavaScript development. I'll check it out. I'm going to start this evening as I'm not doing it. So, Angular started working with Angular in February 2013. And we're going to be coupling whether I kind of realize that it is different than the previous frameworks that I applied. It's tagline from its website. It is TML enhanced for my apps. That's tagline now when in 2013 when I started Angular, the tagline was super heroic MVC framework or something. But it's not really a framework. It's just this. This is what Angular is. This is its most powerful feature. This is the thing that helps well-architected client-side apps. In my opinion, it has practically problem of client-side development by bringing the dog to life. And so now, again, this is the architecture that I try to achieve with Angular. I'm not going to go into how I kind of try to do that. So, yeah, step one before anything. In order to build proper client-side applications with Angular, you need to forget that engine you exist. It exists because, well, the reason is because it kind of puts a global state on the template that is being loaded for a specific URL in your application. And that is bad. That kind of headers the growth of your code base in a scalable manner as opposed to as well as your requirements, please. And after that, well, since the software is engineering complex application, Angular requires this and I also since I use it requires this. So, you need to set up the controllers model. This is the link to get a repository of an application who's in here and who I created yesterday. There are loads. Actually, I don't think it will load because of slow internet connection or something. So, if you guys are too many people, you can go to it. So, all the controllers, basically create a module for your application controllers and then you register all the controllers that the application uses for that. Then you set up your directives, the services, all of them are the same structure. The link to the repository is there at the end of the talk and you can check it out after the work. You know, the templates basically require this text plugin and all cast the templates beforehand. So, that requires basically remove the templates into the minify application file and set up the router configuration. Now, this is something that I think is different from most Angular developers. I have this small tool called R, which basically kind of gives me the functionality of underscore.extent. And through it, I kind of set up different configurations on different nodes. So, if you look at this page, the URL page, visit tags, it has the type of visit tags and the part you can create after visits. And this, this route basically has this configuration. And then the application, when this application loads up this route, it uses this configuration to set it so far. So, basically that's router config and then you have to initialize the application. This is the standard stuff. You can find this and except the router, you can find most of that in any AngularJS require.JSC. So, this is the way it starts up. Then what's important to do is to wrap all of your DOM in a controller. What I mean by that is that in your next .html, you need to have the whole thing under the control of a master controller. So, that basically you can control everything that is happening in your application. What are your own code in your controller? Then you control the sub templates, the sub parts of your DOM using the router config and your controllers. So, for example, if you look at this master controller, it goes this one template. You can set up a flow meter. One template basically loads like an app or one template. And if you look at app controller, we have this dev over here which encapsulates the whole application and the application control. And this dev over here is controlled by an app controller. What this app controller basically does is that whenever the route changes, it meets the parent template defined on the route, parent template configuration defined on the route and sets that up as the parent template over here. And this causes the property of parent basically to load. A simple example for this would be, yeah, so if you look at manufacturers, as you can see the body template over this load inside load here and this contains this DOM that's controlled by the app controller and for the load manufacturers, your router config tells it to load the parent template app.manufacturers. This is basically app slash manufacturer storage schema. This is loaded over here. There you have a template controller which is controlled by another controller and has all the data. It does the interaction using the API service with the application API gets the data and loads it up in the scope variable which is then used to display all this stuff. And this approach is pretty powerful because you can use this to go into any level of hierarchy which you need. So, for example, over here we have for manufacturers, we have different widgets which is, if you check out the URL, that's like inside this view is loaded differently and loads up different data for different manufacturers. And how do you set that up? So, I mean, router.js, that depends your configuration to load it. So, if you check out this route, manufacturers, manufacturer ID widgets, we set the parent template over here. You have to have the manufacturers for parent. And we take a sub-parent template which is manufacturer of widgets. If you check out the parent template, it's just basically equals manufacturer name and loads of the sub-parent template over here. The sub-parent template for widgets basically is again very similar to any other training view in this application. And so, I hope you have understood what I meant by this. Avoiding a GPU and using router configuration to load up different nested views in your application and controlling them via the controllers that you need to control it. I need a yes to move forward. Please someone say yes. Okay, so someone asked me a question right now. I didn't understand why NGVU should not be used. Because NGVU kind of, if you use NGVU that would kind of replace only the requirement for this. Sorry, this is wrong in this one. Yeah, that you can only set up one view to work with NGVU, right? Yeah, it doesn't allow nested views also. You can use NGVU include and do the same thing inside my template. But how do you decide that for this for your route? The parent view has to remain the same, but the child views have to change. How do you decide that? While you're doing this controller, I would do another controller. Because you would go to the application via something. And that's something I took in the router because that kind of hoops into the URN that has been loaded. Plus there is also something called Angular URN. Yeah, Angular URN is there, but it's like, if you're working with the same culture, I think it's actually better than that. If you just use OK for the nested view, for example. So it's like this, it's something extra. It's better for your application, it's better for your code base. There's only one nested view. This one is our nested view. Basically, it may look like that it's only about nested views, but what it allows you to do is to really bifurcate your application into different views, which are controlled by different Outlook controllers, ask where you need them, and that allows you to build very tight UI interactions in your applications. For example, I'll just show you something. This app was made in the late, this is something better. This is the admin panel of the current version, sorry, version 2.0. I'm kind of loading videos of your blog. I'm the YouTube player working over here. I can either load a new video from this panel or I can upload this video. I'll ask them to load it again. Because I've uploaded these videos before, they're better than I've uploaded them. So, I hope you understand. Interactions like this, and moreover, this thing is a direct app. And if you take this approach of propagating your views as much as you need, the addictive kind of come out of your application code. You don't need to think about this separately, especially if they deal with your business logic. This thing was moving a bit over here. If I need to upload photos for a particular event, I could upload it over here. And from there, it became a direct app, which I can now upload to different things that have photos. So, that's probably it. Anything else? Very good. Can I have the mic? I think we can hear him just fine because of the mic. So, should I continue? Yeah, much better now. So, yeah, that's the main thing about building. Well, that's like the main thing. And some other tips to make your life easier when using Angular is using .acue to integrate non-angular async JavaScript APIs with Angular. A simple example of this is the file reader, which I'm using over here. It's loaded the preview of this image inside this box. I will save it there. And how do you do that? Services. So, you just use .acue and .roofscope.apply and just read about promises API and understand promises and integrate things that are easy for us and don't work with Angular directly into your application using .acue for us. And you can live without directors, but you can use them to make your life easier. Like, for example, if you again look at this particular thing. This was one example. This whole code base was easily just occupied inside this thing and used as it is. However, making it into a directive allowed me to avoid that copy we're taking in this simple custom HTML tag. Well, yeah, reuse this thing. And yeah, there are several different... All the DOM interactions, tiny, small DOM interactions that you need to make, which are just UI-specific and don't deal with your business logic. All that stuff can be put in your directories. Like, for example, this box over here is a page to anything. This simple, tedious stuff kind of can be extracted away and put in a directive and then used in different places. The photo holders that you saw over here are directives again. These are directives. Basically, they need something like... I'll show it over here. So, these are directives and they need a valid source. In order to load an image into the source. So, that's really all I want to say about using... Where? That's the link to UI and the API code base. And that's all I want to say about architecting complex applications with AngularJS. And I would like to mention again that even though this might seem trivial, this using just engine through and avoiding engineering to bifurcate your views into different functions, bifurcating your views and contours into different files in order to distribute the functionality. But this is something that really is the key to this whole thing. To building huge applications with AngularJS without really ever falling into architectural backlog or something. Letting you up becomes something that trusses itself under its own weight. So, that's it. The end. Thank you. Yeah, so, I'll show that, you know. You don't know what requires this? You don't know what requires this? Okay, so basically it's something... It's an asynchronous module loader. If you check out this index.html, I have just loaded one JavaScript file over here. Just required of JS. And then in my... I tell it that my application is started over here in half slash main. And over here, I kind of initialize my whole Angular application. Using these few files. There's directives, controllers, services, templates. And this also allows me to build all of this JavaScript HTML to one single file, which is obviously what you need for production purposes. Somebody asked that, you know, how do you work with a runtime for Angular? Yeah, that's the solution for that. Is required JS primarily built for NodeJS that has been adopted into the ground? No, required JS actually is older than NodeJS, as far as I remember. And it's primarily purpose to load modules on demand. But what I find best about it is that I can just put this over here and then forget about adding any more script tags while the program is adopted so that I don't need to make any context which is when adding new files or templates. Yeah, we have built a fairly complex Angular application a lot by controllers and editors. I haven't really seen a need in order to dynamically on-demand load scripts. Why not load everything at the same time? Yeah, I know that. Like I said, I require this value as one... Well, I'm used to it first of all. And then building things with it is very easy. This is a bash file which basically compiles all of this over here. Compiles all after it was built into one single file. So what I found required is great for is it allows you to define what files need to load before a particular Java script was. So the ordering of dependencies is what requires success. In order to the building and the minification and everything it automatically given a target file electrical or what the dependencies are, loads them and puts them in order. Then when you have a lot of third-party dependencies So if you put the scripts in an HTML file in the same order and use the cram file in order to use them it's the same thing which is quite the same. So maybe some people just don't require something as far as you can exclude any other... Well, doing that with Angular is kind of difficult because of the way Angular works. But generally without that, you can't have that easily. But there is a project which does require just plus lazy loading. So it is possible. It's like there's something called .apply called scope.apply which is called on Angular in order to evaluate what all the dependencies have happened and update the DOM accordingly. And if you are lazy loading your controllers you need to add that .apply in the end of your controller declaration in order to have that thing. But it's really too tedious a thing if you're working in a team and with different people to remember that's the thing. Unless you work at Google it's kind of an important mean thing. So yeah, any more questions?