 Thank you. My opening line was going to be, I guarantee that the rest of the presentation isn't going to be as entertaining as what Adam just did, but hopefully it's more informative. So the original title of this was Advanced Architectural Patterns. And as the conference has been going on, I've been watching speaker after speaker come up and talk about these great patterns. And I've been very psyched. On the one hand, on the other hand, I'm like, what am I going to talk about in my presentation? Because I'm going to be talking about a lot of the same things. But my approach is going to be a little bit different because I'm actually going to be showing a lot of code. And so actually just recently I went through the exercise of trying to take a classic backbone application and refactor it to use some of these patterns that I've come to learn and love. So with that, slide number one, I'm going to get right into code already. And yes, I'm using to do MBC, yes, that is. I think it's a good app to show. I know we've all seen it before, but we all know the code intimately. And so I don't have to spend a lot of time telling you what the code does and what everything is, I hope anyway. So if you're not familiar with to do MBC, it's fairly simple. I need to do a task. You can add tasks. You can mark them as complete. I think I can bring the font size down a bit. I can clear the completed ones. I can filter just to see the active or completed ones. Let me complete one so you can see it gets the idea. Okay, so let's take a look at the code. HTML5, we'll see that. We've got some interesting things. I'm just going to point out some interesting things. And the reason I'm pointing them out is because I'm going to be refactoring this code over and over again. Actually, there's seven versions of this. I thought my teammate, Brian Cavalier, often he does his presentations this way. We generate, you know, seven versions of code and demonstrate each one. I thought I could beat them with eight versions, but I'm the biggest match. Anyways, I'm going to point out some things here. We've got a style sheet in the head and we've got some interesting things here. We've got some IDs that point at interesting things in the body. We've got these embedded templates in the popular fake script style. And we have a bunch of scripts at the bottom. You know, pretty, pretty classic. Here we've got a JS folder and we've got some modules here. This is using the module pattern. The first thing we see is the classic example of using the module pattern. Ensuring that we have a global. We ensure that our global exists and we proceed to use it as a namespace. And start decorating it. You know, the classic pattern here. You can see some other examples here. We use this app variable in the things we've decorated all throughout our code. So what's wrong with this situation? I don't know what's wrong with this guy, but what's wrong with this code? First thing is there's lots of script and link tags. It's actually only one link tag. I just was looking at an app the other day and had seven links and then 26 script tags in it. You know, these are blocking. So basically Chrome does a good job of trying to make them as synchronous as possible. But you can actually watch the waterfall in the network tab and you can see that there's actually some blocking going on. So even in the fastest of browsers, all these script elements and links are slowing things down. And how do you do dependency management? In a reasonable size app, how do you manage this stuff here? How can you reasonably call this? Basically, you're manually ordering these script elements here. And the other problem is, of course, global. We've heard time and time again, goals are bad. Identifier conflicts is just the beginning of it. The real problem was what I showed before, and that is that I have to read this entire file here in order to see where the dependencies are because browser globals are way too easy to use, even when you've namespaced them. So now there's dependency here on this to-dos thing. And I have to read the code to know it. So module systems will help us out here. And actually ES6 does a really good job of doing that. And like I said, because it's so easy, it's an exercise in self-control. There's nothing we can do really. I don't even know if the linting tool will help us out enough in order to stop creating this massive dependency graph. I think it was one of the guys yesterday showed a dependency graph. And that's a typical dependency graph, I think, that you get just from using globals and not thinking about, very carefully thinking about your architecture. So yes, a great solution is to use JavaScript models. And let's take a look. I did a refactor on that. Okay. So the first thing I did is let's take a look at index.html. See that the style sheet's gone. Let's show you where that goes in a minute. And again, these are my patterns. These are my favorite patterns. And there are many ways to do this right. So I'm not going to get up here and start stomping and say, this is always the right thing. But you guys will notice that there's no more script elements in the bottom. And there's just one in the head. We can put this at the top and we can put it at the bottom. It really depends on your overall strategy. If you're going to try to get some content up to the user first or if the content's really described in your application, your application is going to build the content, then you can put the script text anywhere. And actually, this app is so damn small. The HTML is that it really doesn't matter too much what the script element goes. So you can see that this script is actually going to pull in. It's going to pull in curl.js, which is a module loader. And let's take a look quick here. So before, the way this was structured was a JS folder and all the JavaScript was just showed in this one folder. And Tim was making me feel really nice when he showed basically this component-driven structure for the application. This is my favorite way to do it. So I created, I didn't want to break this up into too many small components because it just would have been a myriad of files. But I wanted to break it up into at least some components. So this is to-dos folder where I put all the to-do-ish stuff. You can see we've got, we've got a view here for to-dos. I'm using common JS modules here. You can see that the typical common JS, we're going to require a few essential things. We're going to require a few application-level things. And then eventually we're going to export something. This is going to get configured. I agree with Tim. Config step and application launch should be separate processes. So I just split them up here. And this is just a typical, you know, require JS slash AMD config. All right. So what's the advantages here for modules? The module loaders are obviously non-blocking. This is going to go fast. You can better organize your code. The appendage management is all built in because of these requires. You're being explicit about your dependencies. Namespacing is actually configurable. I can change this namespace and all the dependency management is to work. And most importantly, the dependencies are explicit. There's nothing stopping me from taking this require, though, and embedding it somewhere down in the code. So there is a certain level of discipline that needs to happen with common JS. With ES6, that's actually fixed because you can no longer embed the import statements or the export statements down somewhere in code. They have to be at the top level. So they're always, they're much more visible. So the problem of visualizing the map by looking at the source code gets a lot easier. So yes, thank you, Tim, for going over all this stuff for me. So let's take a look at this. I just did look at that. But what's the problem with this? There's still a lot of dependencies. If I go back in here, look at this module right here. It has six dependencies just to get started. I don't like that. I am actually anti-dependency. I will get rid of every single dependency I can. And that seems like a really strange thing to say because you need things to come together in order to make your application work. I'm going to show you a few strategies here. One of the reasons I do not like dependencies is because when I go to write my tests, now I've got to figure out how to mock or stub those dependencies so that I can isolate the thing that I'm testing. And when you're pulling them in with require, that means you have to mock, require somehow or circumvent it because now it's a system that's actually bringing in your dependencies. So one solution to deal with this is inversion of control. And in a very quick summary, inversion of control is strategies and patterns where instead of trying to grab resources from within your code, the code, the resources and dependencies are injected in. They come from outside. And so this actually gives you a lot of flexibility. And we're going to go over three of these very quickly. We're going to go over dependency injection, AOP and this composition plans. So dependency injection is, oh, we saw it yesterday. So that's great. I don't need to really go over into much detail. But as we saw presentation yesterday, you can inject dependencies into the constructor. There are other ways to inject dependencies too. You can inject them as properties. But the way the backbone models and views work, they really need to go into the constructor because you're going to be working with them pretty much during the construction phase of the model of the view. And this prevents you from having to mock the environment because programmatically we're going to be inserting things rather than allowing the system to give us the things we want. And this also makes it easy for the implementation of that thing that's injected. The dependency can change from moment to moment. So you can start up your app in a different environment and inject other things, whereas with require, you have to go through this mapping configuration to get things to switch around. And you can actually make runtime a thing inside what to inject if you're injecting rather than requiring. So let's take a look at an early version of that. So with this version, all I did was change some things around. You can see there used to be six dependencies here. Now there are only three. And instead, I'm doing something very similar to what we saw the other day, and that is using the options of the initialized method to inject some of the dependencies. So specifically here, I'm injecting to-do filter and to-do template. So I'm injecting this to-do filter here, which is an embarrassingly small module. Let me back up a second. When I first just converted over from globals to modules, that's all I did is took every single global, everything that's hanging off the global, and turned it into a module, so that's why I ended up with this one here. Don't worry, we're going to get rid of this module later. I'll show you. The other thing I'm doing here that Tim showed as well is using text templates as modules as well. So these get pulled in as requirements. Just thinking I should have showed what that looked like before we went with dependency inversion. Just to show you one step at a time. So let's take a look at what this looks like now. So view, like I said, now only has what I'm calling infrastructure or essential required now. So what's nice about these is, obviously, we're going to be coding against these. So it's great to have them there available to us while we're defining, while we're authoring this here. To inject these would be just kind of weird. The other thing is that during testing, you kind of need to trust something somewhere. So in tests, can you trust these things? And I think the general answer is yes, you need to trust your third party libraries. And so I'm not worried about the required here or not having to stub these because I'm going to just trust that they work. So again, here's another view. All that requires here are the three essentials. Injected are the other things that it uses. If you remember, this deduce was app.deduce before and it was just streamed throughout the app now. I'm making it a property and referring to it as a local property. Let's take a look at main.js, which I'm going to show you what the difference is here or your .js branch. Okay, so main.js was pretty simple before. Main.js basically just to get the application running. There's this little work around here that I was having some issues with backbone, not automatically adding the jQuery. I don't know if it's supposed to do that automatically in common.js or not, but it didn't seem to link that. And then our application is really simple. We create a view, create a router, and then just start up the view. And actually the router code itself would actually start the history. Now our code in main is a little more interesting. We're pulling in all of the components that were interested to get the application started, requiring them here rather than all over the code. We're bringing them into one location. And we're creating some interesting things here as well. One problem with the original source code was that some of the modules defined instances in some of the defined classes. And I switched it over to all defined classes. So that now it's doList, actually defines a toDoList instead of a toDo's. And we create the toDo's here and then inject it into our application view as an option. Similar with the filter, the filter. We require it in our main and then inject it in the places that it was needed. So what have we done here? We've moved all those dependencies that were in each of those files into one central location. And the central location now is in charge of creating all of these modules that we're using and making sure each one gets a reference to the dependencies it needs. So why? What does that do for us? And the answer is not a lot holds so far. The first thing that it does is to eliminate some of these dependencies so now I don't have to mock them at the require level, at the environment level. Instead I can just inject something. And that thing I inject, obviously, is going to be a mock our stuff. So like I said, this is just a halfway point. This doesn't feel compelling to me. This all that dependency injection was, I would be like, okay, but don't worry, this is the halfway point. You'll get all the way through and you won't have cows laughing at you. So there's a problem here, though, and that main module went from a couple of lines of code to all this. That feels kind of big. But what can we do about that? So let's break it up a little bit. Rather than have one big, you can imagine in a larger application, this doesn't make any sense. You can require all these modules all over the place. You can have this huge long list and then try to figure out how to push everything in the right place. So what we're going to do is I'm going to introduce a concept called composition plan. And to do that, I'm going to switch over to the D92 branch. Okay, and let's see. What's different now? This does look a little bit smaller. At least in terms of requires here, but something changed down here. I'm going to make this font. This is font just right, or can I make this smaller? Okay, so before we had everything in the entire app coming in, and now we've got a much smaller subset. And down here, we've got a whole bunch of extra stuff going on, and I'll explain that in a second. Excellent, explain it right now. Globals are bad. In the DOM world, an ID is basically the same thing as a global. And it's also a resource. It's a dependency. We have a dependency on something. It doesn't have to be JavaScript code. It can be a text template. It can be a CSS file. It can be a DOM node. So in this case, I've gone the extra step, and not only am I removing the dependencies from within the view of knowing exactly how to select things out of the DOM, I've moved that out into the... Move that out into this main already. And this main application has... is what is going to turn into my composition plan. So the other thing I did here is to create another main inside the to-do folder itself. So this main is itself also a module that has a little bit of a composition plan. And composition plans are basically more modules that describe how to put modules together. It's more than that. You describe the entire life cycle of these modules. So it describes how to create them, how to initialize them, how to connect them, and ultimately how to destroy them. And if we create them right, if we have some structure of how we can create them, we can actually make them so they're composable. And so that's what I did here. So here's a composition plan to use section of the application. And you can see that here's the create part of the life cycle. And we actually have a destroyed part of the life cycle as well. The main module pulls that to do composition plan and actually uses it as part of this composition plan to compose the entire application. So you can visualize as you're breaking your application up into these feature areas, these components as multiple people shown on the screens, they like to take the parts of the application that you see on the screen and break them up into various components on the screen, each one with its own view, its own model, its own controller in a pure MVC. But each one also has its own HTML and potentially its own CSS as well. And if I broke up the CSS in this app, that's exactly where it would go to go along right alongside this HTML. So one of the other things that I was able to do was to remove the router.js altogether. Realistically, in an app, router would be more involved, but this router got so so simple that I removed it as a module and brought it right into the composition plan. So now this is starting to feel like, okay, we've got these things here, these composition plans, they're kind of like their own component that's in charge of creating and destroying and initializing and bringing together other components. So this is starting to feel like some sort of pattern, some sort of strategy. And the end result is that the components in here have less dependencies and therefore are a little bit easier to test. And the fact that I have removed the hard dependencies on DOM nodes that are exist in the DOM, then these could also be shimmed. We could load a slightly different environment in the test for our test harness than in production so that we could inject these nodes and then no longer have to set up an exact copy so we can test in whatever environment we see fit, including being able to do something in PhantomJS or a server-side DOM engine. So, again this pattern it's still feeling like am I really getting the benefit I want out of this? When is this going to feel like the right tool? And what's the problem the problem here? There's still some big problems in this code in my opinion and one of them is that we're abusing the model to send events. So one of the things that a user can do in the app is to use this filter down here to decide which of these to-do items are visible and which ones aren't. So here the current app does that is by iterating through all of the models and sending an event on them whether or not it should be visible or not and then doing some calculations by comparing to its state versus this list of hard-coded states to decide when it should be visible and when it shouldn't. So it's iterating through this entire list every time you hit one of these it iterates through all these lists and decides to render or not render a particular item. So that's a lot of code to do that. And why are we using data events for doing view type things? Because this really is a view thing the data itself has to do it to-do tasks that doesn't have anything to do with what you're filtering on the screen. So what can we do about that? One way to solve this problem is through AOP. I'm familiar with AOP you already know that it's a way to provide additional behavior to a component. So and it's done through through decorating the methods on that component. So you've got a component A and you want to add additional behavior you can decorate its methods to give it the additional behavior. What's nice about that is that it's not invasive. So if you change the code of this thing at runtime or at compile time you actually add the additional behavior so that the code stays the same, the code stays you don't have to do any additional tests you actually only have to test the additional behavior independently from the component that's being decorated. And what we call these things that this behavior that's added aspects are basically two things one is the behavior itself which we call advice and then how that's applied. And in the simplest case that advice can be applied either before or after the function runs. So if we want to decorate this object here but before this method runs here we want some other thing to happen we would give before advice to this method if we want something to happen after this method runs we give this method after advice. And what's really really nice about this is that the decoration itself is not embedded in the code somewhere it's on the surface area of this object and because it's on the surface area number one this object doesn't need to change directly the code stays the same the second thing is that it's easy to see that because of the way it needs to be applied it's easy to see it's easy to see the dependency or actually I'll show you there's actually no dependency but it's easy to see that something's been added instead of having to read every single line of source code. And of course this helps you follow the single responsibility rule of a module modules should have one responsibility and this behavior is wildly different some sort of side effect then you're not breaking that rule of that solid rule of single responsibility. So I'm going to show this now switch over to p branch see what changed here so number of things changed here first thing that changed is we got rid of this event on the model that we were using we were using this data level event to describe what really is a view level event and then get rid of all this code in here that dealt with toggling x when we just changed it I'll get rid of it I promise so we changed that around a bit so that we made it a little easier for us to refactor and call it I'll show you that in a second so in the main here I added this library called meld meld.js it's part of the Kujo library and it is an AOP tool it lets us add this advice to before and after the advice is around after returning and if you only want to add this behavior to happen when something throws or after it doesn't throw it's got all these built in and I also created this mediator and this mediator is going to embody this additional behavior so I'm going to take the behavior that was inside that view and I'm going to pull it out to this mediator and then we'll apply it and I'll show you how that works here's the mediator I added another part of the life cycle of this this composition plan here and during the initialization phase of this composition plan I'm going to be connecting things together so I'm going to take the application the main view when the filter all method is called on and filter all is the method that gets invoked when you click those click these guys at the bottom here these links down here when that gets called it's going to call mediators set filter method before that it gets called and after it gets called it's going to call the mediators refresh views so before filter all you used to listen for these change events the important part is when you clicked on that like I said you used to loop through the to-dos and for each one you used to call the filter one and trigger this visible event which of course went back to the to-do view and performed this calculation to see if it should be visible or not and then hit or show it in the render method so we're doing all this stuff and now all that is pretty much gone all we're doing now is calling the render method which is actually just redrawing these guys at the bottom here to keep those up to date and that's it that's all that filter all does now is just save a value so that the render method can use that to decide which these should be showing now I love that I'm going to get rid of that too I promise so this behavior is now in this mediator let me show you a little bit more of main and then we added some more after-advice to connect up more things in the mediator and so when the application creates a new to-do item we're going to save that to-do item because remember now that in view before we used to have to loop through all these to-do items and decide which ones were hidden which ones are shown and I've moved all this over to the mediator so now when we create a new to-do item we need to keep track of that and when we destroy one we need to keep track of that and etc so this create to-do view I've added three new behaviors to it and after it executes we save it to do a view we advise it to do a view and then we run this toggle hidden hidden because the initialization of this to-do item we need to decide whether or not that's hidden when it's first created so let's take a look at the mediator so save to-do item we're just going to keep track of these to-do views in a in a hash there's all sorts of ways to save this advise it to do view once we've gotten a new to-do view we can also add some behavior to that and I could take this and put it into a different mediator but I just put it here to keep it all together so every time one of those little to-do views renders we also toggle it to see if it's hidden or not so we do it right during the render there so each to-do view is in charge of toggling itself and then when that to-do view is removed we just remove it from our global list so we're sure that this hash is always up to date so all of that specific logic that was embedded in the view about deciding when to hide our show is now in our mediator here so this mediator its sole purpose is to hold on to these little views and decide whether or not they're going to hide our show so we took that out of the view whose job was to manage the overall view and we took it and we moved it over here what's nice about this is this is extremely easy to test these these functions are seriously easy to test and now because we took all that behavior out of our view that view is also now even easier to test so there's still a major problem here and that is why are we looping through all these things to do something that seems like should be really simple all this DOM manipulation at least the beginning has been bugging me I'd like to get rid of that because DOM manipulation code is code you've got to test and DOM-oriented code just by its very nature at least to me is a lot harder to test than just pure JavaScript so I really, really want to get rid of that so one way to get rid of it is with OOCSS states and so if you're familiar with OOCSS or other structured ways to write CSS the main principles are to separate the the presentation from the structure you know the theme from the way it's laid out on the page as as stubborn Ella Nicole likes to say you know separate the structure from the skin and OOCSS states adds third dimension to that and that is you can actually describe in control application state in terms of the DOM using CSS and so we'll take a look at that here there's a new file here called states.css made some minor changes in these files here there's a new option I'm going to be injecting something called filter classes here and as I promised I'm going to be destroying this ugly mess over here and replacing them with something a little bit nicer and there's a new method called set state classes which is a way that we're going to you'll see that we're going to translate from what the designer because we're pushing some of this job onto the designer what the designer is defining for classes versus what the engineer is defining for classes and we're getting rid of that mediator because I really didn't like that mediator it was a great concept but as soon as I wrote it out I was like this needs to go away because all this DOM manipulation code so we got rid of it in the view the view now does purely what the view is supposed to do and then we're going to get rid of it in the mediator here and move it all over to css so let's take a look at this css really quick so just a couple of rules here that define whether or not something displays or not so we've got basically some display nuns and display blocks and also some other things here that we're going to change the font weight onto things and so if you use your mind a little bit you can figure out that these are the filters down at the bottom that we're going to change and then here we're going to change some to-do list items so what we've done here is we've defined some css classes that define the visual state of the things on a screen are basically our views or pieces within the views so these guys here are to-do items and these filters down here we're going to define those the states of them whether they're hidden or shown or selected or not selected by these css rules and when you use these we're going to apply these instead of all of our DOM manipulation code in order to change the state of the app and the huge benefit there is basically moving all this JavaScript over to css and css is really I mean that's what this job is for is to manipulate the DOM or not manipulate the DOM but change the state of the DOM so let's take a look at that real quick okay it told me I had 35 minutes left and I was expecting that that was not correct so I guess I have 2 minutes left so let's do this real quick I didn't want to pop up on the screen I didn't bother doing some css okay yes let's take a look at this so let's just verify that this still works let me reload this so here's the to-do list itself the to-do app so here's the to-do app and you can see it has a class called all on it and so basically I'm going to set these states on the top level of this view so run out says all now let me do something interesting now I'm going to click on active that one goes away and we can see up here now the class is active can you guys see that now the class was set to active let me go back just in case you missed it so all completed so what's happening here is the css rules are now being applied and all that we needed to do was to change we didn't do really any DOM manipulation except to change an attribute so all of that the looping code that we had in there to loop through all these guys or keep track of them or do whatever it's all gone all we do now is change one attribute and then these styles kick in and let me just show you one real quick here it is right here here's the class that we had defined in our css file these conditions are satisfied so basically what I've done is that completed class right there describes an application state so if the state of the app is completed and the state of this particular to-do item is completed then you can see that display is blocked but by the way we set up these classes the application state is completed but the list item itself to-do item is not completed then display none so bang so we got rid of all that code and so I love that that made me happy when I did that so time warp just in time because I'm out of time you can imagine that eventually we were going to refactor more and more pieces and more and more pieces and we only really get about into the immersion of control principle here and then I threw in the OOCSS just to help get rid of some code but what I want to show you next is a little bit about data binding I'm going to do this really quick and I know data binding is one of those ferocious topics and everybody can do you love it or you hate it again I think it's just one of those tools that you should use if you want to rendering is great and data binding works really quick and one of the reasons I love data binding is that we all worry about instantiating and destroying our JavaScript objects but the DOM itself is a way bigger hog of RAM than our JavaScript objects in many cases so that's not universally true and just in this to-do MVC app itself every time you added a new to-do item the main view was re-rendered five times and so basically it was re-rendered and let go five times in a row and garbage collection in the browser is not very good because the browser will basically not do it as much as it can and just keep grabbing more RAM off the operating system as much as it can until the operating system pushes back and that's why you have to restart Chrome or Safari or whatever every couple of days because it ate everything up so we're going to look at this a little bit anyways so anyways I do think that there are solutions that you can can do with your rendered views to try to bring them as small as possible but data binding solves a lot of the same things and I'm actually going to show you a version of data binding that has clean templates and there's a nice benefit to that and that benefit is because you've got these clean templates that are pure HTML and pure CSS you can actually get really good separation and that allows parallel iterative development between the design team and engineering team let me show you just that really really quick so I am going to totally cheat and rather than totally keep refactoring and factoring we started with a pure Kujo app this is the Kujo reference app and we went back and we put in back bone here here are the different components of the app we broke up the control section where the filters are the create section which is the part of the to do let me see up here this is the create section up here to create a new to do we have the footer section which is the part down here at the bottom and we have a list section which is this entire part in the middle so we broke this up into tiny components each one has its own HTML template and and then we have got some top level application things here so let's look at this controls for the quick here is the HTML template itself one thing you might notice that is missing is you know the familiar if statements and other things that you would find in you know mustache or templates instead this is really pure HTML and with these other kinds of tags in here and actually I'd love to show you one that this tag is missing because you can actually build this without any tags at all in here what's nice about this is this real HTML here this will actually run in a browser so what that will allow us to do is to actually create a design harness and so I did that I created this design harness called controls what controls does is loads just that piece of the app and put it up on the screen and I'll show you so this is just the control section and I can play with how it's supposed to behave in the real app real app and with one of these left this is supposed to go away this is not going away there it goes okay so it goes away so I want to just test that behavior here me the designer want to make sure it works correctly I can test to see if there are zero or many to do items and I can test to see if other things happen as expected so for instance if there's only one item left I want this to read item left I can test this so I'm testing this component in isolation and what's really really nice about this is I don't even need any kind of back end system to do this because these are standalone unit all these guys here they don't rely on any kind of back end system all they need is some way to load them and so if we look at this controls harness here all it consists of is CSS that we need a couple of buttons that we saw at the top and this is DOM zero type stuff on click then handle as any designer can deal with this stuff and then this boilerplate script that the designer just needs to sorry this one down here to make sure the designer cuts and pastes that in there and then this is pretty much done so anyways I hope that gives you a couple ideas about some alternative designs design patterns and if you want to find out more about some of the tools we didn't get to look at many of them today but we've got a lot of tools in the Kujo Toolkit now and you can go do that and here's some resources we've got some great tutorials out there I really encourage everybody who thinks they want to learn a little bit more about some of the things we have in our toolkit to go and take a look at them and if you're interested in a more thorough investigation of IOC this is one of the best articles on the web thank you very much